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