On Sun, 15 Mar 2026 at 20:27, Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> On 3/15/26 18:49, Emanuel Spiridon via Std-Proposals wrote:
> >>
> >>
> >> On Sun, 15 Mar 2026 at 14:00, <std-proposals-request_at_[hidden]
> <mailto:std-proposals-request_at_[hidden]>> wrote:
> >>
> >> I would expect an interface that avoids "typename" and "::type",
> >> e.g. employing an alias template.
> >>
> >> Thank you for the suggestion. This has been implemented using a _t
> suffix alias template following the convention in <type_traits>.
> >>
> >> Do we get subsumption, i.e.
> >>
> >> f(is_real auto)
> >>
> >> is more specialized than
> >>
> >> f(is_number auto)
> >>
> >> ?
> >>
> >> If not, that feels like causing a bad bang-for-the-buck ratio
> >> of this facility.
> >>
> >> Jens
> >>
> >> Native subsumption is not achievable in a library pure form since it
> requires concept relationships that the compiler can trace.
> >
> >Yes, and we have constraints with fold expansions.
> >
> >> Subsumption could be added if this method is pursued for language level
> implementation.
> >
> >What is the minimum feature that the language would need to add
> to support subsumption? I note that we already have fold-expanded
> constraints.

>

>Jens
>
 I will also note that I recommend fold-expanded constraints.
However, when working with large constraint families,
merge_tags_and_types_t works better since you don't have to worry about
duplicated types.
Merge_tags_and_types_t uses a struct for deduplicating type_tag_list
contents.

Also, the minimum feature that the language would need to add to support
subsumption in this case would be a way to declare subsumption.
It is the easiest to implement, even though it puts all the logic to the
user.

However, if you meant minimum as in the least work for the user, it would
have to be a way to track the type-tags that go into merge_tags_and_types_t
separately of types.
And so, the compiler will always choose the more specific
overload/specialization.