IMO, fixed-width multiple precision support for any reasonable bit width
ought to be provided automatically, if not specified as an option
(essentially, at least bitfields that are "as native as possible"). It
should be able to work as the underlying type of an enum (like a "wide
bitmask enum"), so not just another treatment of std::bitset.

The proposal might be better refined by being a bit more specific with
something along the lines of "int_fast128_t".

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.
Otherwise, the code can express a more relaxed width requirement just
using "int_least128_t", allowing an emulation without warning.

That said, I haven't seen an implementation that provides the "least" or
"fast" variations as anything but aliases.

On 2/10/2024 17:36, connor horman via Std-Proposals wrote:
> It seems weird to me that we'd have a mandatory type alias that
> doesn't correspond to a standard integer type.
> Otherwise, I'd very much like to see standard support for int128.
>
> On Sat, 10 Feb 2024 at 19:18, Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> I've essentially finished my proposal for 128-bit integers:
>
> https://eisenwave.github.io/cpp-proposals/int-least128.html
>
> Please share your thoughts :)
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>