Date: Fri, 19 Jan 2024 10:50:40 +0100
Il 19/01/24 10:20, Tiago Freire via Std-Discussion ha scritto:
> Sorry in advance if I am misunderstanding the interpretation of the
> standard.
>
> I understand that the standard states that only certain types should be
> allowed, but the issue specifically is how the signature is defined.
> If one were to follow that definition to the letter the following should
> be available:
>
> template< class T >
> constexpr T add_sat( T x, T y ) noexcept;
>
> but if that ever happens wouldn't that be game over? A library
> implementer can then specialize the listed types that would then be
> visible to the translation unit,
> but as far as I know there's no requirement that would prevent an
> overload in a non-constexpr context where the implementation is not
> visible from being used.
I think there's a fundamental misunderstanding: that signature is not
conforming.
The Standard Library specification uses an exposition style which is
discussed here:
> https://eel.is/c++draft/description
This tells you how to properly interpret the description of the rest of
the library. In general, https://eel.is/c++draft/conforming talks about
what conforming implementations can and cannot do.
The functions signatures themselves are not to be taken literally; for
instance, an implementation is free to add `noexcept` to a function that
is not otherwise marked as such in the Standard
(https://eel.is/c++draft/res.on.exception.handling#5.sentence-1).
For add_sat, https://eel.is/c++draft/numeric.sat#func-2 says:
> Constraints: T is a signed or unsigned integer type ([basic.fundamental]).
And the interpretation of that is:
https://eel.is/c++draft/description#structure.specifications-3.1
> Constraints: the conditions for the function's participation in overload resolution
Which means: a conforming implementation must not make `add_sat`
available to overload resolution if T is not an integer type. "How
exactly" is up to the implementation (SFINAE, constraints,
compiler-specific magic, the Standard doesn't care). The signature above
is non-conforming.
In other words: what you claim is broken and should be fixed by adding
concepts, is already using concepts (or equivalent).
My 2 c,
> Sorry in advance if I am misunderstanding the interpretation of the
> standard.
>
> I understand that the standard states that only certain types should be
> allowed, but the issue specifically is how the signature is defined.
> If one were to follow that definition to the letter the following should
> be available:
>
> template< class T >
> constexpr T add_sat( T x, T y ) noexcept;
>
> but if that ever happens wouldn't that be game over? A library
> implementer can then specialize the listed types that would then be
> visible to the translation unit,
> but as far as I know there's no requirement that would prevent an
> overload in a non-constexpr context where the implementation is not
> visible from being used.
I think there's a fundamental misunderstanding: that signature is not
conforming.
The Standard Library specification uses an exposition style which is
discussed here:
> https://eel.is/c++draft/description
This tells you how to properly interpret the description of the rest of
the library. In general, https://eel.is/c++draft/conforming talks about
what conforming implementations can and cannot do.
The functions signatures themselves are not to be taken literally; for
instance, an implementation is free to add `noexcept` to a function that
is not otherwise marked as such in the Standard
(https://eel.is/c++draft/res.on.exception.handling#5.sentence-1).
For add_sat, https://eel.is/c++draft/numeric.sat#func-2 says:
> Constraints: T is a signed or unsigned integer type ([basic.fundamental]).
And the interpretation of that is:
https://eel.is/c++draft/description#structure.specifications-3.1
> Constraints: the conditions for the function's participation in overload resolution
Which means: a conforming implementation must not make `add_sat`
available to overload resolution if T is not an integer type. "How
exactly" is up to the implementation (SFINAE, constraints,
compiler-specific magic, the Standard doesn't care). The signature above
is non-conforming.
In other words: what you claim is broken and should be fixed by adding
concepts, is already using concepts (or equivalent).
My 2 c,
-- Giuseppe D'Angelo
Received on 2024-01-19 09:50:43