> It's environmentally disastrous and has no sensible use cases. The net value to the world from bitcoin is massively massively negative.

I agree.

> _BitInt behaves very differently from other integer types, e.g. no promotions or implicit conversions.

Well, that's true, but what I meant is that the infrastructure for
multi-precision arithmetic already has to exist in compilers. It had
to exist to a limited extent so that long long could be
software-emulated on 32-bit or 8-bit platforms, and _BitInt extended
the required infrastructure even more.

Keep in mind that the proposal does not make uint128_t mandatory, only
uint_least128_t, so the type could be _BitInt(128) in disguise (with
traditional conversion/promotion rules).

Does GCC support any targets where bytes are not octets? If not, the
implementation effort is still relatively limited because at least the
type is padding-free and a power-of-two-multiple of the byte size.

I still fail to see a strong argument against making it mandatory.
Even if it has to be software-emulated, that's more of a performance
issue that the user has to keep in mind, than a problem for compilers.
Why is long long not optional on 32-bit targets if software emulation
is not acceptable?

> I don't think that's conforming. I don't think the standard gives permission for those large differences to not work.

Based on what Niebler says in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1522r1.pdf
§4.2, as far as I understand it, implementers can just define the
difference_type to not cover the whole range and ignore the problem.

> I still disagree. No existing ISO C++ code uses that type, so adding the overload for it does not change the meaning of any valid code.

The ISO C++ code that I've provided in the example uses that type and
its meaning would be changed. There may not be a single C++ compiler
that would accept the program, but still.

We're really getting deep into technicalities here though. Yes, the
implementation could provide those extra overloads without breaking
any *compilling* code. Regardless, the wording changes in the proposal
should be made so that it's not just *effectively* OK, but *actually*
OK.