On Sun, 11 Feb 2024, 00:20 Jan Schultke via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> I've essentially finished my proposal for 128-bit integers:
>
> https://eisenwave.github.io/cpp-proposals/int-least128.html
>
> Please share your thoughts :)


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

"QoI (Qualify of Implementation)" is another typo.

Better support for bitcoin is an anti-feature IMHO.

There are a number of assumptions in the paper that seen to exclude 32-bit
and smaller systems. Existing implementations do not support 128-bit
integers on all platforms (and MSVC doesn't support them at all). Similarly
for std::float128_t, that's an optional type and not universally supported.
Adding a mandatory int_least128_t doesn't seem trivial at all. Unless I
missed it, this isn't mentioned anywhere. This is a major problem for the
proposal. If the new types were optional so not required on 16-bit and
32-bit platforms the proposal would be much less difficult.

std::timespec is only a 128-bit type when std::time_t is 64-bit, which is
not universal (although the 2038 epochalypse is approaching so that's
starting to change for some platforms).

"Also, if there exists at least one standard library which implements these
features, it is assumed that they can be adapted into other libraries with
relative ease."
As the maintainer of such a library: we already support __int128 on some
platforms, but that doesn't mean we can support it on all platforms.

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.

If your intention is that the existing random number generators and
distributions could be instantiated with uint128_t then that would require
wording changes to [rand.req.genl]. 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.