> long long long is dead on arrival. “long long” is already consider
> ridiculous repetition of key words, just give it a proper name.
>

People would just use std::int_least128_t or std::int128_t in practice, so
the aesthetics of the "long long long" spelling don't matter that much.


> You will soon realize that RSA 1024 is 1024 bits, so you also need the
> 256bits/512bits and then the 1024 bit numbers.
>
> And next you will be asking for a “long long long long long long” (did I
> get the number of longs right?… I think so)
>

That's why the proposal doesn't make much sense despite 128-bit being
well-motivated; _BitInt can be used for any width.

What OP is proposing doesn't even seem to be a mandatory minimum of 128
bits, but a type that has the same minimum as long long, but is recommended
to be wider. I think this will just lead to an unreliable, non-portable
type.

In any case implementing a type that has no hardware equivalent is a bad
> move. Specially because this is and A/B problem.

What you want is the ability to do multi-precision arithmetic, something
> that computers have been able to do for years, and to do that you think you
> need a bigger type, instead of actually making multi-precision available.
> To make things worse a bigger type doesn’t actually allow you to do
> multi-precision any better
>

> There is nothing special you can solve with 128bits that you couldn’t have
> solved with 64, the only reason you just don’t do it with 64bits it’s
> because you don’t know how to implement higher bit count operations with a
> lower number of bits. The number 128 isn’t magical. It will not all of a
> sudden make things work.
>
> What you want is this:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3161r3.html
>

There are plenty of problems that you need 128 bits for, and definitely
won't need any more for. For instance, implementing 64-bit modular
arithmetic, implementing 128-bit decimal floating-point, time and currency
calculations (64-bit often isn't enough but 128-bit is almost too much),
etc.

Having to do 128-bit arithmetic by gluing together two 64-bit integers is
operating at the wrong level of abstraction anyway. It makes many
optimizations that operate on integers totally impossible because the
middle-end is robbed of the ability to tell that something is a 128-bit
operation, rather than a long sequence of 64-bit operations. It's extremely
important that LLVM has an i128, i256, etc. type so that you only lower to
64-bit in the compiler backend, while enabling all the N-bit integer
mathemtical optimizations.

By your logic, int64_t should also not exist on a 32-bit architecture, and
int16_t shouldn't exist on an 8-bit architecture because people should just
use multi-precision arithmetic. This would be disastrous for writing
portable code, just like it's disastrous for portable 128-bit arithmetic
not to have a 128-bit type. Target-specific lowering should happen deep in
the compiler backend, not in a high-level programming language targeting
the abstract machine.