Hi Giuseppe,
Thanks,
It is my misunderstanding then. I will take that into consideration in the next revision of the document.


-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_lists.isocpp.org> On Behalf Of Giuseppe D'Angelo via Std-Discussion
Sent: Friday, 19 January 2024 10:51
To: std-discussion_at_[hidden]pp.org
Cc: Giuseppe D'Angelo <giuseppe.dangelo_at_[hidden]>
Subject: Re: [std-discussion] Extended overflow arithmetic library

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,
--
Giuseppe D'Angelo