Date: Sat, 10 Feb 2024 18:27:05 -0800
> `int_fast128_t` is `int_least128_t` but the fastest type that suits it - not `int128_t`. You could (in theory) have a faster type that's larger than `int128_t`.
This usually isn’t the case on modern systems, but for consistency, I think (u)int_fast128_t and (u)int128_t should be added as well. Of course, (u)int128_t would be optional.
> It seems weird to me that we'd have a mandatory type alias that doesn't correspond to a standard integer type.
This is certainly something to discuss, but I don’t believe the standard mandates this. The fixed width floating-point types from C++23 also don’t all have corresponding standard floating-point types.
It’s another possibility to add a standard integer type as was done in C++11 with `long long`, but 128-bit processors are not mainstream yet, and we probably need to think of a better name than `long long long`.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of connor horman via Std-Proposals
Sent: Saturday, February 10, 2024 5:26 PM
To: std-proposals_at_[hidden]
Cc: connor horman <chorman64_at_[hidden]>
Subject: Re: [std-proposals] 128-bit integers
`int_fast128_t` is `int_least128_t` but the fastest type that suits it - not `int128_t`. You could (in theory) have a faster type that's larger than `int128_t`.
On Sat, 10 Feb 2024 at 20:16, Jan Schultke via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
> IMO, fixed-width multiple precision support for any reasonable bit width ought to be provided automatically
That sounds like _BitInt.
https://eisenwave.github.io/cpp-proposals/int-least128.html#bit-precise-integers
explains why I didn't choose to propose it this way. In short, it's a
massive language change and doesn't even get you 128-bit integers in
the form you want.
> The proposal might be better refined by being a bit more specific with something along the lines of "int_fast128_t".
It's unclear to me what the difference between that hypothetical
approach and my proposal is. Mandatory int_least128_t gets you
int128_t on the architectures we care about, and that's ultimately
what matters. This *is* the fast 128-bit integer type.
> That way, if there isn't a "fast" version that fits in a register (or has a corresponding subset of instructions), a warning would be emitted.
A warning saying what? "You're using int_fast128_t but it's not
fast!"? How would this be worded, and is this even in the scope of the
standard? Quality-of-implementation diagnostics generally aren't.
> That said, I haven't seen an implementation that provides the "least" or "fast" variations as anything but aliases.
They are required to be aliases in the C++ standard. How else would
you provide them?
This usually isn’t the case on modern systems, but for consistency, I think (u)int_fast128_t and (u)int128_t should be added as well. Of course, (u)int128_t would be optional.
> It seems weird to me that we'd have a mandatory type alias that doesn't correspond to a standard integer type.
This is certainly something to discuss, but I don’t believe the standard mandates this. The fixed width floating-point types from C++23 also don’t all have corresponding standard floating-point types.
It’s another possibility to add a standard integer type as was done in C++11 with `long long`, but 128-bit processors are not mainstream yet, and we probably need to think of a better name than `long long long`.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of connor horman via Std-Proposals
Sent: Saturday, February 10, 2024 5:26 PM
To: std-proposals_at_[hidden]
Cc: connor horman <chorman64_at_[hidden]>
Subject: Re: [std-proposals] 128-bit integers
`int_fast128_t` is `int_least128_t` but the fastest type that suits it - not `int128_t`. You could (in theory) have a faster type that's larger than `int128_t`.
On Sat, 10 Feb 2024 at 20:16, Jan Schultke via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
> IMO, fixed-width multiple precision support for any reasonable bit width ought to be provided automatically
That sounds like _BitInt.
https://eisenwave.github.io/cpp-proposals/int-least128.html#bit-precise-integers
explains why I didn't choose to propose it this way. In short, it's a
massive language change and doesn't even get you 128-bit integers in
the form you want.
> The proposal might be better refined by being a bit more specific with something along the lines of "int_fast128_t".
It's unclear to me what the difference between that hypothetical
approach and my proposal is. Mandatory int_least128_t gets you
int128_t on the architectures we care about, and that's ultimately
what matters. This *is* the fast 128-bit integer type.
> That way, if there isn't a "fast" version that fits in a register (or has a corresponding subset of instructions), a warning would be emitted.
A warning saying what? "You're using int_fast128_t but it's not
fast!"? How would this be worded, and is this even in the scope of the
standard? Quality-of-implementation diagnostics generally aren't.
> That said, I haven't seen an implementation that provides the "least" or "fast" variations as anything but aliases.
They are required to be aliases in the C++ standard. How else would
you provide them?
-- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-02-11 02:27:10