Date: Sun, 11 Feb 2024 14:37:03 +0000

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.

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.

Received on 2024-02-11 14:38:19