Date: Tue, 25 Nov 2025 17:40:23 -0800
> On Nov 25, 2025, at 4:40 PM, Lev Minkovsky via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Hello all,
>
> I wanted to float an idea of an additional extended precision integral type.
>
> The C++ 26 assortment of fundamental integer types (bool, char, short, int, long and long long) are designed to be thin abstractions over the underlying CPU instructions. As such, they are easy to implement and provide very good performance. There are however use cases which necessitate different kinds of types. They can be classified into 3 broad “buckets”.
>
> Arbitrary precision computing. For example, commonly used RSA cryptography keys vary from 1024 bits to 4096 bits.
The problem with this example is that the cryptographic and non-cryptographic uses of multiprecision arithmetic are diametrically opposed - high performance multiprecision arithmetic is catastrophically bad for cryptographic purposes, and the contra: cryptographically safe multi precision arithmetic is significantly slower than what is possible absent those constraints.
There’s also a question as to whether you want arbitrary precision or multiprecision - that is whether the integers have a fixed size, or whether they grow over time.
> Known precision calculations. We already have some support for this in the form of fixed width integer types (Fixed width integer types (since C++11) - cppreference.com <https://en.cppreference.com/w/cpp/types/integer.html>).
Not sure what you mean here? Are you just saying guaranteed bitwidth?
> Extended precision calculations. Some CPU architectures make it possible to do math with higher precision than long long without significant performance penalty.
I assume you mean an implementation of this feature could make use of these on hardware that supports it.
> The bit-precise integers introduced in P3666 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3666r1.html> aims for all these scenarios. I foresee however that it may be difficult to quality-standardize and even more difficult to quality-implement. Some implementations will very possibly be reluctant to commit to it, because their user base would not consider it high priority.
But this is true of any multiprecision library? _BitInt(128) is no more or less difficult to implement when spelled that way vs `__int128_t`, but none of these suggestions support the first point talking about arbitrary precision.
>
> As a complimentary alternative, we can address the 3rd bucket by adding a yet another integer type long long long, with implementation-defined width that would not be less than that of long long. For the platforms where the extended precision is irrelevant (embedded targets, possibly freestanding systems), the implementers can define it as an alias for long long. The desktop and server targets can opt for long long long to have 128 bits.
I would really like to avoid adding new ambiguously named types. If we really want to have wider integer types we should make the width explicit rather than referencing notionally hardware defined sizes - `long long` could in principle be a wide variety of different sizes even though notionally it is 64bits, the semantically correct progression would be for it to be 128 bits on 64bit hard because ‘long’ is meant to be related to the machine word size. In practice it isn’t so continuing to abuse that and similar terms doesn’t seem to be the correct path forward.
>
> With this new type and its unsigned variant, we will also get new literal suffixes LLL and ULLL. Thus, instead of writing a 128-bit zero as static_cast<_BitInt(128)>(0), we would be able to do it simply as 0LLL.
This last point implies you aren’t asking for extended or arbitrary precision, you’re asking for int128_t as an explicitly named primitive type, not a new feature (_BitInt(128) exists) or anything similar. Int128_t also would not support the initial stated rsa use case (even ignoring security issues).
Could you more clearly describe exactly what it is you are asking for? 128bit, multiprecision, and arbitrary precision integers are all different concepts, and have different use cases.
Cheers,
Oliver
>
> If there is an interest in exploring this approach further, I can write a proposal for C++ 29.
>
> Thank you all for your attention –
>
> Lev Minkovsky
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> Hello all,
>
> I wanted to float an idea of an additional extended precision integral type.
>
> The C++ 26 assortment of fundamental integer types (bool, char, short, int, long and long long) are designed to be thin abstractions over the underlying CPU instructions. As such, they are easy to implement and provide very good performance. There are however use cases which necessitate different kinds of types. They can be classified into 3 broad “buckets”.
>
> Arbitrary precision computing. For example, commonly used RSA cryptography keys vary from 1024 bits to 4096 bits.
The problem with this example is that the cryptographic and non-cryptographic uses of multiprecision arithmetic are diametrically opposed - high performance multiprecision arithmetic is catastrophically bad for cryptographic purposes, and the contra: cryptographically safe multi precision arithmetic is significantly slower than what is possible absent those constraints.
There’s also a question as to whether you want arbitrary precision or multiprecision - that is whether the integers have a fixed size, or whether they grow over time.
> Known precision calculations. We already have some support for this in the form of fixed width integer types (Fixed width integer types (since C++11) - cppreference.com <https://en.cppreference.com/w/cpp/types/integer.html>).
Not sure what you mean here? Are you just saying guaranteed bitwidth?
> Extended precision calculations. Some CPU architectures make it possible to do math with higher precision than long long without significant performance penalty.
I assume you mean an implementation of this feature could make use of these on hardware that supports it.
> The bit-precise integers introduced in P3666 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3666r1.html> aims for all these scenarios. I foresee however that it may be difficult to quality-standardize and even more difficult to quality-implement. Some implementations will very possibly be reluctant to commit to it, because their user base would not consider it high priority.
But this is true of any multiprecision library? _BitInt(128) is no more or less difficult to implement when spelled that way vs `__int128_t`, but none of these suggestions support the first point talking about arbitrary precision.
>
> As a complimentary alternative, we can address the 3rd bucket by adding a yet another integer type long long long, with implementation-defined width that would not be less than that of long long. For the platforms where the extended precision is irrelevant (embedded targets, possibly freestanding systems), the implementers can define it as an alias for long long. The desktop and server targets can opt for long long long to have 128 bits.
I would really like to avoid adding new ambiguously named types. If we really want to have wider integer types we should make the width explicit rather than referencing notionally hardware defined sizes - `long long` could in principle be a wide variety of different sizes even though notionally it is 64bits, the semantically correct progression would be for it to be 128 bits on 64bit hard because ‘long’ is meant to be related to the machine word size. In practice it isn’t so continuing to abuse that and similar terms doesn’t seem to be the correct path forward.
>
> With this new type and its unsigned variant, we will also get new literal suffixes LLL and ULLL. Thus, instead of writing a 128-bit zero as static_cast<_BitInt(128)>(0), we would be able to do it simply as 0LLL.
This last point implies you aren’t asking for extended or arbitrary precision, you’re asking for int128_t as an explicitly named primitive type, not a new feature (_BitInt(128) exists) or anything similar. Int128_t also would not support the initial stated rsa use case (even ignoring security issues).
Could you more clearly describe exactly what it is you are asking for? 128bit, multiprecision, and arbitrary precision integers are all different concepts, and have different use cases.
Cheers,
Oliver
>
> If there is an interest in exploring this approach further, I can write a proposal for C++ 29.
>
> Thank you all for your attention –
>
> Lev Minkovsky
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-11-26 01:40:34