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