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.

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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals