Date: Wed, 29 Mar 2023 11:04:32 +0100

On Wed, 29 Mar 2023 at 10:51, Bo Persson via Std-Proposals <

std-proposals_at_[hidden]> 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_at_[hidden]> 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.

std-proposals_at_[hidden]> 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_at_[hidden]> 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.

Received on 2023-03-29 10:04:46