Know that after installation of the project, you can use .h, .hpp, and even without any extensions like this:
#include <webpp/routes/router>

Somehow for some reason Clion IDE
says it needs :: before std. I do have "webpp" namespace and I do have custom polyfills in ::std namespace but no ::webpp::std.
There must be something wrong with my code; I don't trust a code that doesn't compile!

You know what? I'm just gonna replace them all with ::std::
I'm so tired of thinking 😅

Thanks @ostapmk for suggesting it.

So anyone has any suggestion about which library is better for SIMD?
I hear talks about this one finding its way into STL:
https://github.com/VcDevel/std-simd

C++20's concepts have the potential to remove header dependencies and circular dependencies specially in the header-only libraries.

Adding ..._concepts.h files really help boosting up compile time I suspect.

You know I'm doing some magic template metaprogramming in the project when you seem me lurking around boost::mpl library.
Not even CLion is able to understand that thing 😅

This is how I report software bugs

I'm designing a global extension system which makes it possible to add some extensions where-ever you need some extensions. Those extensions may require some other extensions, which may have conflict with other extension requirements; so I'm using this meta-programming magic to solve that issue and only inherit from a unique list of extensions.

The Tweet

Yep, I'm writing tests for C++20 concepts as well.

Somehow these bugs are all over the project for no apparent reasons what so ever 😂

Fixed one of them. Can you spot? 😁

Why did I think this was a good idea? Seriously, WHY?

Is it that bad? Any new ideas on what should I do with this?
1. Replace with std::any (Too slow maybe!?)
2. Use extensions (Becomes complicated maybe?)
3. Use inheritance (Don't even think about it!)
4. Use void* + size + extensions (I don't know what I'm talking about 😂)
5. ...???

Okay how do you do a "at least one of these" in C++20 concepts?

I'm gonna add extensions to everything; including:
- Protocols
- Interfaces
- Routers
- Requests
- Responses
- Contexts
- Headers
- Bodies

Each extension may require other extensions from the same level, or even lower levels which the type itself has access to at compile time.
This way for example you can add an extension to the router and see the result in the context or even the requests and response.
An example would be cookies which will be added to the headers level but with a little of boiler plates, you can use it as a router level extension.

This is a nice way but I wonder if a unified extension type would be a better solution.

Read this from top to bottom, or bottom to top. Your choice!

Today was the worst day
and don't try to convince me of that
there will be some good moments everyday
if you look carefully,
life is hard
even though
many times good things happen
happiness doesn't exists
and it's not true that
many things depend on us
I'm sure you agree that
the environment that we're in
affects directly on
our behavior
not everything is in our control
and you never see me saying
today was a good day

Collaborative Response (Collaborative output):

This is the the way that multiple sub-routes each prepare parts of a response.
For example:
Sub-route 1 will prepare the template (header and body).
Sub-route 2 will prepare for example the dynamic stuff in the page that are still boiler plate (where the user profile picture would go and notification stuff and these kinda stuff)
Sub-route 3 fills a complex table for example
Sub-route 4 fills a the rest of the stuff in the page
Sub-route 5 ...

I haven't seen this idiom anywhere yet. With the new routing system you'll be able to do this in the future as easy as it's possible. You just have to add one extension into your router. That's it.

I think C++20 concepts are great ways to reduce header dependency hierarchy, compile time, and maybe even code bloat; specially for header-only libs.
How? By introducing a concept for every type that the library user needs to use; in a different header file.

This way half of your library is not dependent on the other half of the library; they just need the concept header files of those types not the types themselves.

Of course if you're not using templates, don't use this tricks since introducing templates to the code adds more compile time but if you already doing TMP, then the chances are that with concepts that are not actually checking the exact type, you can reduce header dependency.

Most of the time your library doesn't need to know the actual type, it just needs to know what you can do with that type; which of course leads to more general code.

Of course C++20 modules also can fixes the same problems in most cases but not all of them.