On Sun, 11 Feb 2024, 16:39 Jan Schultke, <janschultke@googlemail.com> wrote:
> 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?

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


> 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.

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



> 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.

Nope, unsigned long is 32-bit on 32-bit Unix-like systems, except for little-used outliers like the x32 ABI on x86_64.



> 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)?

It has to be emulated in software, so the performance is bad.



> 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 don't think that's conforming. I don't think the standard gives permission for those large differences to not work.


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.


But it's implementation defined whether they do provide that typedef, and none do. So the only way to use the type today is as an extension, and so it's perfectly fine (in terms of conformance) to change the meaning of code using that extension. Any implementation that doesn't provide std::int128_t is free to support to_string(__int128).





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.

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.



> 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.

What valid code would change meaning if I added that constructor to libstdc++ tomorrow?