Date: Wed, 26 Nov 2025 21:48:35 -0500
On Wed, Nov 26, 2025 at 6:14 PM Lev Minkovsky via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello all,
>
>
>
> Thank you for your active participation in the discussion about extended precision types.
>
>
>
> There is a better way to accomplish what I am looking for. Virtually every hardware architecture provides some support for double precision math. For example, 32-bit platforms can effectively and directly do 64-bit operations, and 64-bit platforms – 128-bit operations. A good deal of that support is already available in existing C++ implementations.
>
> We now have the following set of integral types:
>
> size-constrained fundamental types (e.g., long long is at least 64 bit).
> fixed-size library types, aliasing to fundamental types (e.g., int16_t)
> the potential future wide gamut of bit-precise types (e.g., _BitInt(48)).
>
>
>
> In addition to those, we can introduce the following word-length-dependent types:
>
> _Single. unsigned _Single
> _Mult2, unsigned _Mult2.
>
> The _Single types will be aliases of some C++26 fundamental types. For example, on x64, _Single can be aliased to long long. The _Mult2 types on 32-bit platforms can aliased to (unsigned) long long, and on 64-bit platforms introduce standard 128-bit integer types.
>
>
>
> If we want to, we can also have the respective literals. For example,
>
> auto x = 1sl;
> auto y = 1m2;
>
>
> Here, x will be a single precision integer, and y – double precision integer, both equal to 1.
>
>
>
> All this should be easy to implement with native-level performance, and therefore we should expect quick and wide adoption.
>
> Please let me know if you think this is proposal worthy.
It's unclear to me why someone would use these types. That is, what
code am I writing where I am 100% fine with an integer that's only
64-bits in size (ie: I don't need it to be bigger), but I would
specifically want it to be 128-bits on 64-bit platforms? If I just
needed at least 64-bits, I'd use `int_least64_t` or `long long` or
`_BitInt(64)`. So what am I doing where I want it to be 128-bits on
64-bit platforms?
What is the programmer thinking about when they use `_Multi`?
You also talked about "quick and wide adoption", as if that's a
primary goal of the proposal. I don't feel that a proposal should
exist primarily because it can be adopted quickly. That might be a
consideration, and certainly if people think that a proposal will be
ignored by meaningful compilers, that sounds like a problem with the
proposal. But it shouldn't be that important.
<std-proposals_at_[hidden]> wrote:
>
> Hello all,
>
>
>
> Thank you for your active participation in the discussion about extended precision types.
>
>
>
> There is a better way to accomplish what I am looking for. Virtually every hardware architecture provides some support for double precision math. For example, 32-bit platforms can effectively and directly do 64-bit operations, and 64-bit platforms – 128-bit operations. A good deal of that support is already available in existing C++ implementations.
>
> We now have the following set of integral types:
>
> size-constrained fundamental types (e.g., long long is at least 64 bit).
> fixed-size library types, aliasing to fundamental types (e.g., int16_t)
> the potential future wide gamut of bit-precise types (e.g., _BitInt(48)).
>
>
>
> In addition to those, we can introduce the following word-length-dependent types:
>
> _Single. unsigned _Single
> _Mult2, unsigned _Mult2.
>
> The _Single types will be aliases of some C++26 fundamental types. For example, on x64, _Single can be aliased to long long. The _Mult2 types on 32-bit platforms can aliased to (unsigned) long long, and on 64-bit platforms introduce standard 128-bit integer types.
>
>
>
> If we want to, we can also have the respective literals. For example,
>
> auto x = 1sl;
> auto y = 1m2;
>
>
> Here, x will be a single precision integer, and y – double precision integer, both equal to 1.
>
>
>
> All this should be easy to implement with native-level performance, and therefore we should expect quick and wide adoption.
>
> Please let me know if you think this is proposal worthy.
It's unclear to me why someone would use these types. That is, what
code am I writing where I am 100% fine with an integer that's only
64-bits in size (ie: I don't need it to be bigger), but I would
specifically want it to be 128-bits on 64-bit platforms? If I just
needed at least 64-bits, I'd use `int_least64_t` or `long long` or
`_BitInt(64)`. So what am I doing where I want it to be 128-bits on
64-bit platforms?
What is the programmer thinking about when they use `_Multi`?
You also talked about "quick and wide adoption", as if that's a
primary goal of the proposal. I don't feel that a proposal should
exist primarily because it can be adopted quickly. That might be a
consideration, and certainly if people think that a proposal will be
ignored by meaningful compilers, that sounds like a problem with the
proposal. But it shouldn't be that important.
Received on 2025-11-27 02:48:49
