Why can't we just return a "type"? wouldn't that be cooler and simplify TMP in general?

One of the alternatives to that code, is to use this "lazy evaluated" alternative to std::conditional_t.

GCC says sorry; so cute 😍😊

Template stack type overflow. 😂

Have you ever reached to this error?

This string::join will help you:
- join multiple types that can be converted to strings
- it finds the best allocator among them by ranking them
- it'll only require one allocation

Here's the source: https://github.com/the-moisrex/webpp/blob/dev/core/include/webpp/strings/join.hpp

With the help of TaskWarrior and the two bash script files, gtask and gtask-markdown in the project, we can easily add the TODO table in the README.md file so every visitor can easily know about them and hopefully that'll help them to contribute more easily.

I've re-implemented so many string-related functions/types/... just because lots of string-related stuff in the STL doesn't support any character type other than "char".

And I've been making them better and better.

Seriously pro tip in C++20 concepts:

Do NOT use your instances of your concepts (the types that match your concepts) directly if they're going to be all over the place.

You WILL change the concept at some point. Use middle-man type aliases to extract information out of them.

I think I should propose this to be added to the C++ Core Guideline if it's not already there.

It could get really messy if you don't follow this. Trust me, I currently getting bitten by it already! 😅

I don't have the luxury of searching 😂

I end up doing this;

C++ is stupid 😅

The choice between
1. Traits and SubTraits
2. TraitsPack and Traits
seems really hard.

For the first one I have to change lots of things, but it seems more convenient choice!

What do you think?

This is "Interesting, confusing, feels like it should perform better, but you know it doesn't" kinda code.
The benchmark
Inspired by: Printing 1 to 1000 without loop or conditionals

Which one is the best alternative to static_assert(false, "oops")?

With these, you can make the static_assert(false), type-dependent; thus instead of evaluating it at point of compiling the function, it gets evaluated when the function's type is known which means if constexpr statements work in that time.

And also there's a std::dependent_false proposal which in this code is an alternative for always_fasle.

Click here to see the code

There are also alternatives to the "!sizeof(decltype(input))" part which you can see here.