On Wed, 29 Mar 2023 at 10:51, Bo Persson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 2023-03-29 at 11:21, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Wed, Mar 29, 2023 at 10:01 AM Jonathan Wakely <cxx@kayari.org> wrote:
>> By definition, there are no integral types wider than uintmax_t, so if __int128 is wider than uintmax_t, it's not an integral type.
> Do we really want the C++ Standard to redefine English language
> scientific terms?

Yes, it does so all the time.

And it has to, because mathematics is not sufficient to describe the properties of integers in C++. There are no minimum/maximum values of signed integers in maths, no overflow etc. and maths doesn't tell us what happens if you convert INT_MAX+1LL to int.

Mathematics does tell us how unsigned arithmetic works, but still doesn't tell us anything about uint16_t{65536u}, so we still need to define what "integral type" means **in C++**.

> __uint128_t is a type. I think we agree on this point.
> __uint128_t holds an integer. I think we also agree on this second point.
> __uint128_t is an integer type. This seems to be where we disagree.

Yes. The standard says that uintmax_t is the widest integer type.

So, logically(!), if some type is wider, it just cannot be an integer
type. Because that is not allowed.

Exactly. An implementation cannot conform to the C++20 standard if it provides a type which is wider than uintmax_t and models std::integral. It can choose to be non-conforming (e.g. GCC with -std=gnu++20) or it can choose to say that __int128 is an implementation-defined type with similar properties to standard integer types, but which is not in the set of "integral types" **as defined by the standard**. Of course it is a type that holds integers, but so is an enum. The point is that the set of types that are classified as "integer types" **by the C++ standard** is implementation-defined. __int128 is not required to be in that set.