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