> Which code (which is not generic, e.g. templated, anyway) would use it,
but not use conditionals or typedefs or other means to care for the width?

There's actually no int128_t typedef in the standard, even though gcc/clang
have had 128-bit ints as an extension for a while.

So while unrelated, this has encouraged me to draft a proposal adding it
along with int_fast128_t, int_least128_t, and unsigned versions.

On Tue, Nov 25, 2025, 7:48 p.m. Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Why an implementation-defined width?
>
> Which code (which is not generic, e.g. templated, anyway) would use it,
> but not use conditionals or typedefs or other means to care for the width?
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Lev Minkovsky via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 26.11.2025 01:40
> *Betreff:* [std-proposals] Extended precision integers
> *An:* std-proposals_at_[hidden];
> *CC:* Lev Minkovsky <levmink_at_[hidden]>;
>
> 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”.
>
>
>
> 1. Arbitrary precision computing. For example, commonly used RSA
> cryptography keys vary from 1024 bits to 4096 bits.
> 2. 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>).
> 3. Extended precision calculations. Some CPU architectures make it
> possible to do math with higher precision than long long without
> significant performance penalty.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>