> There's a typo in the language-agnostic search: /int128|int128 is missing an underscore (it's there in the actual search, just not the link text in the paper).

Thanks, I've fixed it and the other typo.

> Better support for bitcoin is an anti-feature IMHO.

It's not supporting Bitcoin per-se to be fair; Bitcoin is just a good
example of a currency where the fraction is very small. What's the
matter with "supporting Bitcoin" anyway?

> Existing implementations do not support 128-bit integers on all platforms (and MSVC doesn't support them at all).

Fair point. I should have pointed out that __int128 is not mandatory.
I don't believe that this is a major problem though. The
infrastructure for _BitInt already exists and is mandated by the C
standard, so something like that could be used on other platforms, or
__int128 should be made available on more.

> Adding a mandatory int_least128_t doesn't seem trivial at all.

I agree that the effort is not trivial. However, Clang and GCC already
support _BitInt(N) for N well over 128, so the work is essentially
done. I'm not sure when Microsoft intends to support _BitInt and to
what extent though. Also, it's still tremendously easier to support
128-bit integers than 128-bit floating-point. The overwhelming
majority of standard libraries is already robust against arbitrary
bit-sizes. Also, the infrastructure for multi-word operations must
already exist to support long long on 32-bit platforms. I don't see
any outrage over having to support 64-bit long long on 8-bit targets,
so I don't see 128-bit is that big of an issue either.

> std::timespec is only a 128-bit type when std::time_t is 64-bit, which is not universal

I was under the impression that time_t is required to be unsigned long
at this point, and that's 64-bit for Unix-like systems. Thanks for the
correction.

> we already support __int128 on some platforms, but that doesn't mean we can support it on all platforms

What's the hurdle to supporting a 128-bit+ type on all platforms (not
necessarily an exactly-128-bit type)?

> Your discussion of iota_view fails to mention that a standard int128_t type would be a valid template argument for iota_view, and so would require a new integer-like class type like _Signed129 (or more). Libstdc++ already has such a type because we already allow iota_view using 128-bit integers, so we have a difference type that's even wider.

It doesn't mention it because implementers are free to do what they
want in this case. I imagine that libc++ maintainers will continue
doing what they're doing and define difference_type to be __int128.
This is compliant, but does produce UB for large differences. I see it
as QoI. I should have made that issue more clear in my proposal though
and investigated further.

> And implementations would need to do 256-bit arithmetic, e.g. for the product of two 128-bit values in the transition function of std::linear_congruential_engine<uint128_t, ...>. That might not require wording changes to the standard but the additional implementation effort is worth calling out.

Thanks, I will take a closer look at how the RNGs in different
libraries would be affected.

> I don't agree with illegal. The implementation can add overloads of any standard function as long as they don't affect the semantics of valid ISO C++ programs.

It would not be permitted. See the newly added example in
https://eisenwave.github.io/cpp-proposals/int-least128.html#lifting-library-restrictions

The heart of the issue is that the implementation can already provide
std::int128_t, so adding overloads is altering the result of overload
resolution from <ambiguous overload> to <success>. If std::int128_t
was not allowed to exist in prior standards, this would not be
relevant.

Of course, there are no implementations that provide std::int128_t
yet, so no code is affected. However, if future implementations
provided a 128-bit integer type, then it would presumably be available
in C++11 mode and upwards. Therefore, this isn't a non-issue, but a
practical one.

> Would adding bitset(same_as<unsigned __int128> auto) prevent any valid ISO C++ programs from compiling?

Yes, and the problem is the same as with to_string. Making it a
template doesn't solve the problem.