C++ Logo

std-discussion

Advanced search

Re: Extended overflow arithmetic library

From: Giuseppe D'Angelo <giuseppe.dangelo_at_[hidden]>
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,
-- 
Giuseppe D'Angelo

Received on 2024-01-19 09:50:43