Date: Sun, 29 Aug 2021 19:08:38 -0400
On Sun, Aug 29, 2021 at 2:00 PM 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?
I see no reason why that should be done.
Yes, integral types are all of those things. But those are
*incidental* properties of integral types; they aren't what makes them
integral types. So if you have a piece of code that is going to
constrain a template based on getting an integral type, then you're
asking if it is one of this specific set of fundamental types. The
other properties are still true, but they're not what you're asking
for.
The only way I could see this mattering is if you have two versions of
a template, one for integer types and one for user-defined ones. But
the user-defined requirements are such that integral types *also*
satisfy them, thus creating a conflict that can only be resolved by
adding a constraint that the type is not a fundamental type.
<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?
I see no reason why that should be done.
Yes, integral types are all of those things. But those are
*incidental* properties of integral types; they aren't what makes them
integral types. So if you have a piece of code that is going to
constrain a template based on getting an integral type, then you're
asking if it is one of this specific set of fundamental types. The
other properties are still true, but they're not what you're asking
for.
The only way I could see this mattering is if you have two versions of
a template, one for integer types and one for user-defined ones. But
the user-defined requirements are such that integral types *also*
satisfy them, thus creating a conflict that can only be resolved by
adding a constraint that the type is not a fundamental type.
Received on 2021-08-29 18:08:55