It got even better than that, now it "default constructs" the ones that you didn't pass too.

But clang doesn't seem to like it. I suppose I need to extract one of those lambdas out as a struct to fix that!

It would be less pretty though :)

Replace a template parameter of a templated type from A to B.

With this you are able to change a template parameter of a type from the old type to the new type that you specify.

This is particularity good for when you have want to change the allocator type from current allocator to the new allocator you want without knowing the templated type.

The source code

I'm going to use this to identify, and change your allocator type after finding the best allocator that matches your needs; but this thing is good for other template meta programmings as well.

Of course this has some limitations as well. For example if your templated type includes "auto" or "decltype(auto)" or any non-type template parameters, you will have a problem. This code only works on templated types that their types are types themselves and won't work on types that include template template (template <template...> typename) template parameters.

Meet tuple_filter; it helps you filter the types inside a std::tuple or any tuple-like type based on a C++20 concepts (or older versions if you'd like).

Unfortunately we're not able to directly pass a C++20 concept as a template so the user of this type has to pass a template<typename> typename template struct containing static constexpr bool value.

See the source code on the Compiler Explorer

I've also implemented this in another way long ago while implementing the"extension system" of this project.
Here's the source code of that implementation on GitHub.

And the code for those 4 TMP utilities are this. 😁

I should/could also add the non-type template parameter replacer as well, but the I don't need it; at least not yet.

You can find the source at the core/std/type_traits.hpp file in Web++ project.

Template meta programming could be better if the language maker do something about it. You can do really interesting stuff with it.

The purpose of this utility that I made was to make sure my allocator_pack can correctly and recursively replace all the allocators in the specified type with the new allocator type that we find is the best choice there.

This way, the fastest allocator in the allocator pack (or I should call it resource pack maybe) is chosen without the user (or the library) explicitly telling it what allocator it should use.