> 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.

The standard guarantees `int` is at least 16 bits, `long int` is at least
32 bits, and `long long int` is at least 64 bits.

Would there be disadvantages to breaking the symmetry that implies `long
long long int` would be at least 128 bits?

On Tue, Nov 25, 2025, 7:40 p.m. 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”.
>
>
>
> 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
>