C++ Logo

std-proposals

Advanced search

Re: [std-proposals] 128-bit integers

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Sun, 11 Feb 2024 13:47:09 +0200
On Sun, 11 Feb 2024 at 02:18, 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 :)

First of all, looks nice and comprehensive, you have certainly done
your "homework" well and diligently.

I have two questions:

1) I'm a bit.. ..baffled by
"However, the standard library contains a large amount of artificial
hurdles which make it impossible to provide library support for
extended integers. Even if there exists an extended 128-bit integer,
std::to_string(std::int128_t) cannot exist, std::bitset cannot be
constructed from it (without truncating to unsigned long long),
std::abs(std::int128_t) cannot exist, among other issues."
I don't understand what that means. Is that talking about a possible
alternative of trying to add such extended integers as pure library
types, or.. <baffled>?
Most of those "impossible" problems seem to be solvable by adding the
right kind of overloads to those functions, which this proposal does.
I don't understand what exactly
is impossible. :)

2) "The proposal makes no changes to the core language. "
Okay.. so.. do you mean that existing conversion/promotion rules will
Just Work, so there's no need to do any language-level accommodation
of these new integer types? Then sure, the language itself doesn't
change.. ..but perhaps the way of using the language does. In the same
section you list some "oddities", and I think there may be an
additional one, one where users try to write an overload set that
covers
all of the integer types in the language, so now they may have to
extend such overload sets, to avoid ambiguities and other surprises?

Received on 2024-02-11 11:47:22