On Wed, 29 Mar 2023 at 09:45, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Mar 29, 2023 at 12:07 AM Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> > You're assuming that __uint128_t is an integral type.
>
>
> Do you remember Barney the Dinosaur? The big purple dinosaur guy that
> sang songs on television with children, "I love you... you love
> me..."?
>
> I can dress up in a big purple Barney suit, but that doesn't make me a
> dinosaur. And I can put a miniature made-to-fit tuxedo on my dog, but
> that doesn't make him a business man -- he's still a dog.
>
> It doesn't matter if you're from another planet, or if your first
> language isn't English, the type '__uint128_t' is an integer type. If
> the C++ Standard, or if any given C++ compiler, doesn't recognise it
> as an integer type, then that's a totally different issue.
>

Then take the discussion somewhere else, this list is about the C++
standard.



>
> It isn't at all helpful to have false==std::is_integral_v<__int128>.
> That's ridiculous. We know what an integer type is, we know what
> 128-Bit means, so __uint128_t is of course an integer type whose range
> is 0 through 2^128-1 -- or an 'integral' type if you want to use the
> adjectival/genitive form of the noun.
>

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.

C++ implementations have to choose their poison, they can break the rule
that uintmax_t is the largest type, or they can take an ABI break by
changing uintmax_t, or they can provide wider types that are not classified
as standard integer types. Until C++23 there is no way to do the right
thing.

But we've fixed it now.


>
> The expression 'is_integral_v<T>' should evaluate to true for any
> compiler-built-in type that does mathematical operations on integers
> (i.e. an integral type). Let's keep this simple.
>
> We need to get our feet back on the ground and stop floating around up
> in the clouds with abstract ideas. A rose is a rose is a rose. An
> integer is an integer is an integer.
>

You said "There seems to be a bit of confusion about whether or not it's
okay for uintmax_t to be 64-Bit if the compiler provides a 128-Bit integer
type." I provided the background for that.

If you're not interested in understanding the reason for that confusion,
and what the status quo is, and how it's been fixed for C23 and C++23, find
another mailing list.