On Sun, 29 Aug 2021 at 21:01, Andrew Schepler via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> It seems the C++20 standard library concepts missed out on some requirements for one concept to subsume another. For example, should we consider it incorrect that concept std::integral is not subsumed by std::destructible, std::copy_constructible, std::regular, etc.? If T is a fundamental integer type, then T is regular, but conforming compilers can't use these facts in partial ordering of templates. Should this be a Defect Report? Or has this sort of issue been considered by the Committees, or is anyone working on a related paper?

As far as I understand the situation, it was a deliberate choice not
to try to define a subsumptive hierarchy for number concepts,
when the concepts were added. I'm not entirely sure about the history
and intended purpose of integral, floating_point seems
to be used by relatively new additions, and both of those seem like
specific-purpose half-hacks that just allow defining templates
with a constrained template parameter. I have heard ruminations
related to mdspan that it would be welcome to have a set
of number concepts. It would seem unwise to try to shoehorn it into
the existing integral/floating_point concepts since that
could change overload resolution in existing code. To even entertain
that approach, we would need to see compelling examples
of overload sets where you actually need something like a subsumption
relationship between integral and regular, for example,
because you can at least to some extent just write mutually exclusive
overloads (integral vs !integral) to solve those problems.
All in all, I find it very non-obvious that this should be done as an
incompatible change to these existing concepts-that-just-wrap-traits,
as opposed to introducing a new family of number concepts.