On 4/5/26 21:24, Emanuel Spiridon wrote:

> That is intentional, the approach of making a dedicated list makes error
> messages clearer.

That design decision should be in the proposal.

> This proposal targets the specific use case of concept constraints,
> where a named, purpose built type set is preferable over repurposing
> std::tuple or std::variant

Targeting a specific use-case for a general-purpose facility risks
making design decisions that may be reasonable for one use-case but
not for others.

Let me illustrate this with your merge_tags_and_type_t alias. This is
underspecified, but we can deduce from the examples that it either
creates a type-list from a set of types, or creates a flattened
type-list from another type-list and additional types.

Creating a type-list from types is done by

   using natural_numbers = merge_tags_and_types_t<
     unsigned char, /* etc */>;

which is odd, because we could just specify the type list directly

   using natural_numbers = type_tag_list<unsigned char, /* etc */>;

Creating a flattened type-list is done by

   using numbers = merge_tags_and_types_t<
     natural_numbers, float, double, long double>;

I would have expected this to be modeled after existing facilities in
the standard library, specifically tuple_cat, so that it merges
type-lists.

Consider rewriting the proposal by cherry-picking mp_list, mp_contains,
and mp_append from P0949 as these are based on existing practices. P0949
also gives you the proper legalese wording required for standardization.