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