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.

 

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals