On 11/02/2024 14.42, Jan Schultke wrote:
>> 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;

Not really. The implementation shouldn't introduce new names in
namespace std (without __ hiding), because that might interfere
with future standardization.

> 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.

How do I reliably write an overload set with the new integer type,
e.g. extending the operator<<(std::ostream&, ...) one?

That rules out a type alias int128_t = long long, I believe.

Consider a platform where long long = 128 bit:

  long long a = 1;
  int128_t b = 2;
  auto x = a + b;

What's the type of "x"?

I think we want int128_t here, but we get "long long".

> 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?

I don't care about the "least" aliases, I care about the
specific 128-bit integer type that you want.

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

You can't reasonably use <cstdint> least* types to define overload sets.

Jens