> 113bits is 15bits short of 128, and "64/128-bit mixed operations " isn't the same thing as "128-bit operations".

I am aware of that. Keep in mind that compilers keep track of the
value ranges that integers can have. If the optimizer knows that one
of the 128-bit operands is 64-bit at most, it can choose a faster
routine. If the optimizer knows that both operands are 113 bits or
less, it can use quad-precision floating-point operations.

This is actually a very strong argument in favor of 128-bit integers
because ISO C++ does not offer a mechanism through which such
implementation dispatching can be done, based on optimizer knowledge.
It would require runtime branching if the developer wanted it, and
that comes at a cost.

> Having a "128-bit general purpose register" would be my definition of "native support".

That's probably not going to happen for a long time. However, it's
also unclear why a low-level detail such as the lack of a general
purpose register of the right width would restrict very high level
features, such as an integer in the type system.

> Again, it’s X Y problem. You want 128bit because some crypto libraries use it for multi-word arithmetic, not because 128bit is useful.

No, it is not. Just because I have provided crypto as a possible use
case for 128-bit integers doesn't mean that my proposal is about
multi-word arithmetic for cryptographic purposes. This line of
reasoning makes no sense.

128-bit is useful in general, and a large part of the proposal is
library support. A std::mul_wide function does not mean that you can
print 128-bit integers using std::print now. Dealing with library
support is 90% of the proposal's wording changes so how do you keep
missing this point?

> It means that having 128bits won't fix your problem.

It does solve my problem. I needed 128-bit integers to represent the
state of an xorshift128 PRNG. I was unable to do so before, but now I
can.

If you want to double down on this line of reasoning, why have 64-bit
integers at all? They don't solve ALL problems because you still need
multi-precision arithmetic in some cases, so why bother? Why not just
stick with 8-bit integers?

> I'm going to skip NVIDIA CUDA support, as those run on your GPU not CPU.

CUDA kernels can be written to operate both on the host and the
device. This ability of writing C++ code that covers both CPU and GPU
is a great part of the appeal.

> My suggestion would be to remove the stuff related to multi-precision arithmetic from the motivation first and see what's left. I think you will find that it is not allot.

You're suggesting that because you are completely unable to widen your
tunnel vision and see the proposal for a 128-bit proposal instead of a
2x64-bit proposal. It's not a widening arithmetic proposal.