> Just because you think that "extended integer types" already have some semantics, it doesn't necessarily mean that's the right semantics for a new standard-prescribed integer type.

That's not wrong, but I also don't see any obvious issue with using
those existing semantics. Do you?

If anything, there should be a strong reason to make core language
chases and alter these existing semantics, or create a new kind of
integer that is neither standard nor extended. I couldn't think of
any.

> I think we want a new fundamental type for those;

Why? An implementation is already permitted to define a type alias:

> uint128_t = unsigned long long;

What concrete reason do you have to change the status quo and
retroactively disallow this? I also agree that we don't need a keyword
representation and that's one of the reasons I'm not proposing a
standard integer type.

On any "conventional" implementation, unsigned long long will be
64-bit and uint128_t will be unsigned __int128 or some other distinct,
fundamental type. What concrete issue are you solving by mandating
that the int_leastN aliases beyond N=64 must be distinct types?

> And we want the right conversion rules even if "long long" happens to be 128-bits as well on a given platform

I don't see any issues with the existing conversion rules. The rank of
any integer is greater than that of another integer if it has greater
width. What change to these rules is necessary, specifically?


To be fair, one potential issue I see is that when the user writes
overload sets for concrete types instead of templates that accept
integers, writing

> foo(unsigned long long) { ... }
> foo(std::uint_leastN_t) { ... }

... runs the risk of a re-definition error. However, this practice is
arguably already bad because it breaks for any extended integers
(which may already exist), and the user can simply write a function
template which decides a concrete implementation based on if
constexpr. The user can also put the foo(std::uint_leastN_t) overload
into a block such as:

> #if LLONG_MAX < /* 2^128-1 */

C++ provides enough solutions to this problem, and those are really
only problems if one assumes that long long is not 128-bit. Outside of
standard library code, it's not unreasonable to make that assumption.