On Sun, 11 Feb 2024, 19:31 Jens Maurer via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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

But the C standard already allows uintN_t for any N if it provides an
unsigned integer type with width N, no padding bits, and a two’s complement
representation. So an implementation can define uint24_t or uint128_t if
they can support such a type.

So if unsigned long long happens to be 128 bits then it's allowed (but not
required) to define uint128_t.



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