Bit-precise integers

Contents

1. Revision history

This is the first revision.

2. Introduction

In distant history, there have been various attempts at standardizing multi-precision integers in C++, such as [N1692] "A Proposal to add the Infinite Precision Integer to the C++ Standard Library", [N1744] "Big Integer Library Proposal for C++0x", and [N4038] "Proposal for Unbounded-Precision Integer Types", all of which have been abandoned by the authors. However, there has always been some enthusiasm in the committee for such a feature.

I am picking up where they have left off. Whether this results in a C++ feature or adds corpses to the graveyard of multi-precision papers remains to be seen.

2.1. C23

Recently, WG14's [N2763] introduced the _BitInt set of types to the C23 standard, and [N2775] further enhanced this feature with literal suffixes. For example, this feature may be used as follows:

In short, the behavior of these bit-precise integers is as follows:

• No integer promotion to int takes place.
• Mixed-signedness comparisons, implicit conversions, and other permissive feature are supported.
• They have lower conversion rank than standard integers, so an operation between _BitInt(8) and int yields int, as does an operation with _BitInt(N) where N is the width of int. They only have greater conversion rank when their width is greater.
• Widths up to BITINT_MAXWIDTH are allowed, with padding bits being added if needed. BITINT_MAXWIDTH is at least 64.

2.2. P3140R0 "std::int_least128_t"

In parallel, I proposed [P3140R0] which would add 128-bit integers as std::int_least128_t to the C++ standard. It became apparent to me that standardizing just a single width of 128 and not solving the _BitInt C compatibility problem would be futile, so I've stepped away from the proposal. However, the feedback and experience gained from P3140 made it well worth the time spent.

2.3. P3639R0 "The _BitInt Debate"

I've subsequently proposed [P3639R0] "The _BitInt Debate", which shifts the goal to compatibility with C's _BitInt type, and attempts to answer whether the set of types corresponding to _BitInt should be a class template or a family of fundamental types. P3639R0 received much feedback in 2025. First, from SG22:

The WG14 delegation to SG22 believes that the C++ type family that deliberately corresponds to _BitInt (perhaps via compatibility macros) should be... (Fundamental/Library)

SF	F	N	L	SL
8	1	1	0	0

WG21

SF	F	N	L	SL
4	5	0	0	0

The overall sentiment in SG22 was that a fundamental type is "inevitable". This is reflected in the polls. SG6 also saw the paper, but had no clear opinion on the fundamental/library problem. Last but not least, EWG also saw the paper in Sofia 2025, with the following two polls:

P3639R0: EWG prefers that _BitInt-like type be a FUNDAMENTAL TYPE (in some form) in C++.

SF	F	N	A	SA
13	9	9	5	4

Result: consensus

P3639R0: EWG prefers that _BitInt-like type be a LIBRARY TYPE (in some form) in C++.

SF	F	N	A	SA
8	9	14	8	3

Result: not consensus

While the general direction for the paper is clear (fundamental type), there are many contentious design issues, such as the minimum supported BITINT_WIDTH or how permissive bit-precise integers should be with implicit conversions. You can identify the most contentious problems as blocks such as:

3. Motivation

3.1. Computation beyond 64 bits

Computation beyond 64-bit bits, such as with 128-bits is immensely useful. A large amount of motivation for 128-bit computation can be found in [P3140R0]. Computations in cryptography, such as for RSA require even 4096-bit integers.

Even when performing most operations using 64-bit integers, there are certain use cases where temporarily, twice the width is needed. For example, the implementation of linear_congruential_engine<uint64_t> requires the user of 128-bit arithmetic, as does arithmetic with 64-bit fixed-point numbers (e.g. Q32.32).

3.2. Cornerstone of standard library facilities

There are various existing and possible feature library facilities that would greatly benefit from an N-bit integer type:

• As mentioned above, the implementation of linear_congruential_engine<uint64_t> requires the use of 128-bit integers.
• bitset has constructors taking unsigned long long and a to_ullong member function that converts from/to integers. This is clunky and limited considering that bitsets can be much larger than unsigned long long. Bit-precise integers would be a superior alternative to unsigned long long here.
• [P3161R4] proposes library features such as add_carry or mul_wide which produce a wider integer result than the operands. For example: template<class T> struct mul_wide_result { T low_bits; T high_bits; }; template<class T> constexpr mul_wide_result<T> mul_wide(T x, T y) noexcept; Proposals like these are arguably obsolete if the same operation can be expressed by simply casting the operands to an integer with double the width prior to the multiplication.

3.3. C ABI compatibility

C++ currently has no portable way to call C functions such as:

While one could rely on the ABI of uint32_t and _BitInt(32) to be identical in the first overload, there certainly is no way to portably invoke the second overload.

This compatibility problem is not a hypothetical concern either; it is an urgent problem. There are already targets with _BitInt supported by major compilers, and used by C developers:

3.4. Resolving issues with the current integer type system

_BitInt as standardized in C solves multiple issues that the standard integers (int etc.) have. Among other problems, integer promotion can result in unexpected signedness changes.

Overall, the current integer promotion semantics are extremely surprising and make it hard to write correct code involving promotable unsigned integers. Promotion also makes it hard to expose small integers (e.g. 10-bit unsigned integer) that exist in hardware (e.g. FPGA) in the language, since all operations would be performed using int. Unconventional hardware such as FPGAs are pillar of the motivation for _BitInt laid out in [N2763].

3.5. Portable exact-width integers

There is no portable way to use an integer with exactly 32 bits in standard C++. int_least32_t and long may be wider, and int32_t is an optional type alias which only exists if such an integer type has no padding bits. Having additional non-padding bits may be undesirable when implementing serialization, networking, etc. where the underlying file format or network protocol is specified using exact widths.

While most platforms support 32-bit integers as int32_t, their optionality is a problem for use in the standard library and other ultra-portable libraries. There are many use cases where padding bits would be an acceptable sacrifice in exchange for writing portable code, and bit-precise integers fill that gap in the language.

4. Core design

The overall design strategy is as follows:

• The proposal is a C compatibility proposal first and foremost. Whenever possible, we match the behavior of the C type.
• The goal is to deliver a minimal viable product (MVP) which can be integrated into the standard as quickly as possible. This gives us plenty of time to add standard library support wherever desirable over time, as well as other convenience features surrounding _BitInt.

4.1. Why not a class template?

[P3639R0] explored in detail whether to make it a fundamental type or a library type. Furthermore, feedback given by SG22 and EWG was to make it a fundamental type, not a library type. This boils down to two plausible designs (assuming _BitInt is already supported by the compiler), shown below.

The reasons why we should prefer the left side are described in the following subsections.

4.1.1. Full C compatibility requires fundamental types

_BitInt in C can be used as the type of a bit-field, among other places:

Since C++ does not support the use of class types in bit-fields, such a struct S could not be passed from C++ to a C API. A developer would face severe difficulties when porting C code which makes use of these capabilities to C++ and if bit-precise integers were a class type in C++.

4.1.2. Common spelling of unsigned _BitInt(N)

If bit-precise integers were class types in C++, this would cause a serious problem with a common spelling that can be used in both C and C++ headers, even if there was a _BitInt compatibility macro.

There are some workarounds to the problem, but they all seem unattractive:

• Permitting signed and unsigned to be combined with class types in general, perhaps with the effect of applying std::make_signed and std::make_unsigned. This would lead to a bifurcation of the language where both a builtin feature and a type trait achieve the same effect.
• "Blessing" the std::bit_int<N> type-name so it can be combined with unsigned. This would be a highly unusual special case in the language.
• Making _BitInt(...) expand to an unspecified construct that can be combined with signed and unsigned. This means there needs to be a fundamental type, although that fundamental type only acts as a proxy for the std::bit_int class type. Once again, this comes off as an unusual special case.
• Introducing a _BitUint(...) macro for unsigned bit-precise integers, and insisting that both C and C++ developers use this for interoperability. This feels like an unnecessary burden for C developers considering that their spelling works perfectly fine and that we have other design options which keep C code intact.

4.1.3. C compatibility would require an enormous amount of operator overloads etc.

Integer types can be used in a large number of places within the language. If we wanted a std::bit_int class type to be used in the same places (which would be beneficial for C-interoperable code), we would have to add a significant amount of operator overloads and user-defined conversion functions:

• There are conversion to/from floating-point types and other integral types.
• There are conversion to/from enumeration types.
• There are conversion to/from pointers, at least for _BitInts of the same width as uintptr_t.
• Integers can be used to add offsets onto pointers, and by proxy, in the subscript operator of builtin arrays.
• Arithmetic operators can be used to operate between any mixture of arithmetic types, such as _BitInt(32) + float.

Any discrepancies would lead to some code using bit-precise integers behaving differently in C and C++, which is undesirable.

Furthermore, the wb integer-suffix for _BitInt is fairly complicated to implement as a library feature because the resulting type depends on the numeric value of the literal. This means it would presumably be implemented like:

Seeing that properly emulating C's behavior for _BitInt (and its suffixes) requires a mountain of complicated operator overload sets, user-defined conversion functions, converting constructors, and user-defined literals, it seems unreasonable to go this direction.

A major selling point of a library type is that library types have more teachable interfaces, since the user simply needs to look at the declared members of the class to understand how it works. If the interface is a record-breaking convoluted mess, this benefit is lost. If we choose not to add all this functionality, then we lose a large portion of C compatibility. Either option is bad, and making std::bit_int a fundamental type seems like the only way out.

4.1.4. Constructors cannot signal narrowing

Some C++ users prefer list initialization because it prevents narrowing conversion. This can prevent some mistakes/questionable code:

This would not be feasible if std::bit_int was a library type because narrowing cannot be signaled by constructors. Consider that std::bit_int and std::bit_uint should have a non-explicit constructor (template) accepting int (and other integral types) to enable compatibility in situations like:

If such a std::bit_uint<32>(int) constructor existed, the following C++ code would not raise any errors:

This code simply calls a std::bit_uint<32>(int) constructor, and while the initialization of y is spiritually narrowing, no narrowing conversion actually takes place. In conclusion, if std::bit_int was a library type, C++ users who use this style would lose what they consider a valuable safety guarantee.

4.1.5. Tiny integers are useful in C++

In some cases, tiny bit_int's may be useful as the underlying type of an enumeration:

By using bit_int<2> rather than unsigned char, every possible value has an enumerator. If we used e.g. unsigned char instead, there would be 252 other possible values that simply have no name, and this may be detrimental to compiler optimization of switch statements etc.

4.1.6. Special deduction rules

While this proposal focuses on the minimal viable product (MVP), a possible future extension would be new deduction rules allowing the following code:

Being able to make such a call to f is immensely useful because it would allow for defining a single function template which may be called with every possible signed integer type, while only producing a single template instantiation for int, long, and _BitInt(32), as long as those three have the same width. The prospect of being able to write bit manipulation utilities that simply accept bit_uint<N> is quite appealing.

If bit_int<N> was a class type, this would not work because template argument deduction would fail, even if there existed an implicit conversion sequence from int32_t to bit_int<32>. These kinds of deduction rules may be shutting the door on this mechanism forever.

4.1.7. Special overload resolution rankings

Yet another possible future extension would be rankings for overload resolution that take integer width into account.

These overload ranking rules would be difficult or impossible to define using a class type. Of course, they are not proposed, and it's not certain whether such rules are desirable to have, but it would be unfortunate to shut the door on these possible features forever.

4.1.8. Quality of implementation requires a fundamental type

While a library type class bit_int gives the implementation the option to provide no builtin support for bit-precise integers, to achieve high-quality codegen, a fundamental type is inevitably needed anyway.

Furthermore, the compiler frontend needs to understand certain operations to warn about obvious mistakes such as division by zero, shifting by an overly large amount, producing signed integer overflow unconditionally, etc. Use of pre on e.g. bit_int::operator/ cannot be used to achieve this because numerics code needs to have no hardened preconditions and no contracts, for performance reasons.

Last but no least, a fundamental type is needed to speed up constant evaluation. Something like integer division between two bit_int<128> may be much faster as a compiler-builtin operation compared to constant-evaluating a "software division" loop with 128 iterations necessary to implement binary division.

If we accept the premise that a fundamental type is needed anyway (possibly as an implementation detail of a class template), then the class template actively harmful bloat:

• Any arithmetic operation needs to go through overload resolution, competing with countless other operator+s (there are many in the standard library already). Even if implementers special-case these operations to circumvent the (usually awful) diagnostic quality of a failed call to operator+, there remains substantial cost: overload resolution is expensive.
• Every distinct bit_int<N> and bit_uint<N> would be a separate instantiation of a relatively large class template, which would undoubtedly add compilation cost.
• Invocations of member functions or operator overloads may add cost to debug builds and constant evaluation.

4.2. Why the _BitInt keyword spelling?

I also propose to standardize the keyword spelling _BitInt and unsigned _BitInt. I consider this to a "C compatibility spelling" rather than the preferred one which is taught to C++ developers. See also §6.1. Teaching principles.

While a similar approach could be taken as with the _Atomic compatibility macro, macros cannot be exported from modules, and macros needlessly complicate the problem compared to a keyword. Furthermore, to enable compiling shared C and C++ headers, all of the spellings _BitInt, signed _BitInt and unsigned _BitInt need to be valid. This goes far beyond the capabilities that a compatibility macro like _Atomic can provide without language support. If the _BitInt(...) macro simply expanded to bit_int<__VA_ARGS__>, this may result in the ill-formed code signed bit_int<N>.

The most plausible fix would be to create an exposition-only bit-int spelling to enable signed bit-int<N>, which makes our users beg the question:

Why is there a compatibility macro for an exposition-only keyword spelling?! Why are we making everything more complicated by not just copying the keyword from C?! Why is this exposition-only when it's clearly useful for users to spell?!

The objections to a keyword spelling are that it's not really necessary, or that it "bifurcates" the language by having two spellings for the same thing, or that those ugly C keywords should not exist in C++. Ultimately, it's not the job of WG21 to police code style; both spellings have a right to exist:

• The bit_int alias template fits in aesthetically with the rest of the language, and conveys clearly (via "pointy brackets") that the given width is a constant expression.
• The _BitInt spelling is useful for writing C/C++-interoperable code, and C compatibility is an important design goal.

It seems like both spellings are going to exist, whether _BitInt is a keyword or compatibility macro. Since there is no clear technical benefit to a macro, the keyword is the only logical choice.

4.3. Underlying type of enumerations

The following C code is ill-formed:

There is no obvious reason why _BitInt must not be a valid underlying type. However, since this feature is not needed for C compatibility, I do not consider bit-precise integers as underlying types to be part of the MVP. A follow-up proposal could add this feature later, possibly in coordination with WG14.

This behavior should be mirrored.

4.4. Should bit-precise integers be optional?

As in C, _BitInt(N) is only required to support N of at least LLONG_WIDTH, which has a minimum of 64. This makes _BitInt a semi-optional feature, and it is reasonable to mandate its existence, even in freestanding platforms.

Of course, this has the catch that _BitInt may be completely useless for tasks like 128-bit computation. As unfortunate as that is, the MVP should include no more than C actually mandates. Mandating a greater minimum width could be done in a future proposal.

4.5. _BitInt(1)

C23 does not permit _BitInt(1) but does permit unsigned _BitInt(1), mostly for historical reasons (C did not always requires two's complement representation for signed integers). This is an irregularity that could make generic programming harder in C++.

However, there are already plans to lift the restriction for C2y; see [N3644]. Following v3 of the proposal, _BitInt(1) is expected to be valid type, and 0wb should be of type _BitInt(1) rather than _BitInt(2). That proposal also contains some practical motivation for why a single-bit should be permitted.

4.6. Undefined behavior on signed integer overflow

I propose to perpetuate bit-precise integers having undefined behavior on signed integer overflow, just like int, long etc. This has a few reasons:

• bit-precise integers have undefined overflow in C, so this is what users are used to.
• "Solving" signed integer overflow for bit-precise integers is not part of the MVP. Undefined behavior can always be defined to do something else, so there is no urgent need for this paper to address this issue, rather than solving it in a follow-up paper.
• Signed integer overflow having undefined behavior is a much broader issue that should be looked at in general, for all integer types, not just bit-precise integer types. Perhaps hardened implementations could have wrapping overflow with erroneous behavior. In any case, the problem exceeds the scope of the paper.
• It is highly unusual that users would expect signed integer overflow to be well-behaved, such as having wrapping behavior. Adding two positive numbers and obtaining a negative number is not typically useful.
• The undefined behavior here is useful. It allows for optimizations such as converting x + 3 < 0 into x < -3.

That being said, much of the feedback surrounding bit-precise integers revolved around signed integer overflow. If we were to make signed integer overflow not undefined for bit-precise integers, there are two options that may find consensus:

• Make signed integer overflow wrapping. In other words, most operations would be performed as if by casting to the corresponding unsigned type, performing the operation, and casting back.
• Make signed integer overflow wrapping and erroneous. This is mirroring Rust's behavior, and would typically be implemented by detecting overflow on debug builds and in constant evaluation, but ignoring it and letting it wrap in release builds.

4.7. Permissive implicit conversions

Just like any other integral type, the proposal makes bit-precise integers quite permissive when it comes to implicit conversions. This is disappointing to anyone who wants bit-precise integers to be a much "stricter" or "safer" alternative to standard integers, but it is arguably the better design for various reasons.

4.7.1. C compatibility

Firstly, the point of perpetuating implicit conversions is to mirror the C semantics as closely as possible, which leads to few or no surprises when porting code between the languages, or when writing C-interoperable headers.

If we look at how C users use _BitInt, GitHub code search for "_BitInt" language:C yields examples such as:

// mixing signed and unsigned bit-precise integers unsigned _BitInt(128) max128s = 0x7FFF'FFFF'FFFF'FFFF'FFFF'FFFF'FFFF'FFFFwb; // mixing bit-precise and standard integers unsigned _BitInt(4) a = 1u; // mixing bit-precise and standard integers of different signedness unsigned _BitInt(total) bit = 1; // ... including cases where initialization does not preserve values unsigned _BitInt(3) max3u = -1;

If we were to make implicit conversions much more restrictive on the C++ side, it would become very easy to slip up and accidentally write a header that does not also compile in C++.

4.7.2. Difficulty of carving out exceptions in the language

Writing C++ code involving bit-precise integers would be quite annoying and "flag" many harmless cases if the rules were too strict.

To combat this problem, it would be necessary to carve out various special cases. For example, permitting value-preserving conversions with constant expressions would prevent the example above from being flagged.

However, such special cases are insufficient to cover all harmless cases.

Existing C++ code bases that have not used flags such as -Wconversion from the start are likely filled with many such harmless cases of mixed-sign implicit conversions. If bit-precise integer types were introduced into these code bases, refactoring effort may be unacceptable.

Furthermore, discrepancies between the standard integers and bit-precise integers would make it much harder to write generic code:

4.7.3. Picking some low-hanging fruits

While conversions between bit-precise integers and other signed or unsigned integer could be difficult to restrict due to the reasons above, other conversions are much more rare and could more easily be restricted:

• Conversions between bit-precise integers and bool.
• Conversions between bit-precise integers and character types.
• Conversions between bit-precise integers and floating-point types.

It would be reasonable to ban these conversions unconditionally because they are likely to be category errors.

The least harmful of these conversions is a value-preserving conversion from a bit-precise integer to a floating-point type. However, at best, these lack clarity of intent.

4.7.4. Conclusion on implicit conversions

In conclusion, discrepancies between the standard integers and bit-precise integers are undesirable; they introduce a lot of unnecessary problems. There are many harmless operations like T x = 0; and x & mask where mixing signedness is okay, and not every user wants to have warnings, let alone errors for these. Especially errors would make it hard to write headers that compile both in C and in C++.

The final nail in the coffin is that if the user wants implicit conversions to be restricted, they have the freedom to add those restrictions via compiler warnings and linter checks. Having these restrictions standardized in the language robs the user of choice. If C++26 profiles make progress, it is likely that C++ will have profiles which restrict implicit conversions, giving users a standard way to opt into diagnostics.

However, the decision to permit implicit conversions is not set in stone. Especially the conversions described in §4.7.3. Picking some low-hanging fruits could be banned for bit-precise integers without much of an issue.

4.8. Raising the BITINT_MAXWIDTH

The proposal currently does not seek to increase the BITINT_MAXWIDTH beyond what C offers. That is, BITINT_MAXWIDTH may as low as 64. I do not consider an increase of the maximum to be part of the MVP. It's something that can always be done later, if desirable, without any breaking changes.

It also should be stated that increasing the BITINT_MAXWIDTH is not really within the power of WG21 and not even within the power of compiler vendors.

WG21 can define the BITINT_MAXWIDTH as whatever they want to; it is of no consequence because compiler vendors are not going to make that width available when there is no platform ABI for _BitInt(BITINT_MAXWIDTH). If compiler vendors did that, there would be a risk of a massive future ABI break in order to comply with the system ABI, once defined. Without a single platform ABI, there would also be no portable way for code generated by different compilers to interoperate, such as compiling a C library with GCC and using it from Clang-compiled C++ code.

An increase to the BITINT_MAXWIDTH is political posturing. That does not mean that it's entirely pointless. If C++ defined the minimum to be, say, 65'535, this would motivate platforms to define an ABI for large bit-precise integers.

4.8.1. Possible increased BITINT_MAXWIDTH values

Firstly, it should be noted that [P3140R0] got substantial criticism just for attempting to standardize 128-bit integers for embedded developers. As a compromise, it may be reasonable to increase the BITINT_MAXWIDTH only for hosted implementations, not for freestanding implementations. That being said, there two plausible increased minimums:

• 128. Many platform ABIs (see example above) already define an ABI for _BitInt(128). 128-bit integers have been provided by compilers for a long time now, at least by GCC and Clang (__int128). There are heaps of motivation (see [P3140R0]) for 128-bit computation. The calling conventions are also relatively obvious for 64-bit platforms: pass via pair of 64-bit integers.
• 65'535. Both GCC and Clang already support this width. Some cryptographic use cases like future-proof RSA computations need 8192 bits of key size, and at least double that for modular arithmetic. It is unlikely that a cryptographic library needs 4096 bits but does not need 8192 bits at any point, but likely that 65,535 is sufficiently large, even in the next few years.

Beyond that, _BitInt may be tricky to use. When working with Clang's _BitInt(8'388'608), a single + operation could result in stack overflow because the result is 1 MiB large. The user would have to carefully ensure that all objects (including temporaries) have static or dynamic storage duration (i.e. use new or global variables). For these extreme sizes, a dynamically sized integer is more ergonomic. Therefore, setting the minimum to millions feels unmotivated.

4.9. Template argument deduction

The following code should be valid:

This would be a consequence of deduction from _BitInt being valid:

This behavior is already implemented by Clang as a C++ compiler extension, and makes deduction behave identically to deducing sizes of arrays. In general, the aim is to make the deduction of _BitInt widths as similar as possible to arrays because users are already familiar with the latter. It is also clearly useful because it allows writing templates that can accept _BitInt of any width.

While this behavior could arguably be excluded from the MVP, it would be extremely surprising to users if such deduction was not possible, given that appearance of std::bit_int. If deducing N from std::array<T, N> is possible, why would it not be possible to deduce N from std::bit_int<N>?

One thing deliberately not allowed is:

This class-template-argument-deduction-like construct is not part of the MVP and if desired, should be proposed separately. Even if it was allowed, std::bit_int is proposed to be an alias template, and alias templates do not support "forwarding deduction" to CTAD.

4.10. No preprocessor changes, for better or worse

To my understanding, no changes to the preprocessor are required. [N2763] did not make any changes to the C preprocessor either. In most contexts, integer literals in the preprocessor are simply a pp-number, and their numeric value or type is irrelevant.

Within the controlling constant expression of an #if directive, all signed and unsigned integer types behave like intmax_t and uintmax_t ([cpp.cond]), which may be surprising.

The current behavior could be seen as suboptimal because it makes bit-precise integers dysfunctional within the preprocessor. However, the preprocessor is largely "owned" by C, and any fix should go through WG14. In any case, fixing the C preprocessor is not part of the MVP.

5. Library design

When discussing library design, it is important to understand that the vast majority of support for bit-precise integers "sneaks" into the standard without any explicit design changes or wording changes. Many existing facilities (e.g. <bit>) support any integer type; adding bit-precise integers to the core language silently adds library support. The following sections deal mostly with areas of the standard where some explicit design changes must be made.

5.1. Naming of the alias template

The approach is to expose bit-precise integers via two alias templates:

The goal is to have a spelling reminiscent of the C _BitInt spelling. There are no clear problems with it, so it is the obvious candidate. int and uint match the naming scheme of existing aliases, such as intN_t, uint_fastN_t, etc.

The alias names as a whole also act as abbreviations of the core language term (which is copied from C):

• bit_int<N> is a bit-precise signed integer of width N
• bit_uint<N> is a bit-precise unsigned integer of width N

5.1.1. Why no _t suffix?

While the _t suffix would be conventional for simple type aliases such as uint32_t, there is no clear precedent for alias templates. There are alias templates such as expected::rebind without any _t or _type suffix, but "type trait wrappers" such as conditional_t which have a _t suffix.

The _t suffix does not add any clear benefit, adds verbosity, and distances the name from the C spelling _BitInt. Brevity is important here because bit_int is expected to be a commonly spelled type. A function doing some bit manipulation could use this name numerous times.

5.2. format, to_chars, and to_string support for bit-precise integers

I consider printing support to be part of the MVP for bit-precise integers. There are numerous reasons for this:

• Being able to print bit-precise integers is clearly useful. It seems unthinkable that it would not be supported at some point, even if support was not added by this proposal.
• It would take considerable wording effort to exclude support for bit-precise integers from these facilities, only for it to be reverted once support is inevitably added. For example, the expression std::println("{:b}", 100) prints 1100100. This is specified in terms of std::to_chars where base = 2. If std::to_chars does not actually support bit-precise integers, this wording becomes nonsensical.
• The design is obvious. No changes to format are necessary if to_chars supports bit-precise integers.

To facilitate printing and parsing, the following function templates are added:

T is constrained to accept any bit-precise integer type. It would have also been possible to accept two overloads taking bit_int<N> and bit_uint<N> with some constant template argument instead, but this doubles the amount of declarations without any clear benefit.

Such a signature is also more future-proof: the constraints can be relaxed if more types are supported (e.g. extended integer types), whereas a bit_int<N> parameter can only support bit-precise integer, until the end of times. For parsing and printing, this seems short-sighted.

It should also be noted that the existing overloads such as to_string(int) cannot be removed because it would break existing code.

5.3. Preventing ranges::iota_view ABI break

Due to the current wording in [range.iota.view] paragraph 1, adding bit-precise integers or extended integers of greater width than long long potentially forces the implementation to redefine ranges::iota_view::iterator::difference_type. Changing the type would be an ABI break. This problem is similar to historical issues with intmax_t, where adding 128-bit integers would force the implementation to redefine the former type.

To prevent this, the proposal tweaks the wording in § [range.iota.view] so that new extended or bit-precise integers may be added. Dealing with extended integer types extends slightly beyond the scope of the MVP, but it would be silly to leave the wording in an undesirable state, where adding a 128-bit extended integer still forces an ABI break.

5.4. Bit-precise size_t, ptrdiff_t

As in C, the proposal allows for size_t and ptrdiff_t to be bit-precise integers, which is a consequence of sizeof and pointer subtraction potentially yielding a bit-precise integer.

Whether bit-precise integers in those places is desirable is for implementers and users to decide, but from the perspective of the C standard and the C++ standard, there is no compelling reason to disallow it. It would be a massive breaking change if existing C++ implementations redefined the type of these, so it is unlikely we will see an implementation that makes use of this freedom anytime soon.

5.5. New abs overload

The proposal adds the following abs overload:

While abs is not strictly part of the MVP, taking the absolute of an integer is such a fundamental, easy-to-implement, and useful operation that we may as well include it here.

5.6. Using bit-precise integers in <cmath> functions

The proposal adds support for using bit-precise integers in all <cmath> functions:

This is done simply for consistency with C: after some consulting with WG14 members, I am under the impression that C's <tgmath.h> functions deliberately all integers types (including bit-precise integers), not just as the result of defective wording. Consequently, _BitInt can be passed both to the type-generic sqrt macro as well as to the regular sqrt(double) function.

5.7. Lack of random number generation support

Support for random number generation is not added because too many design changes are required, with non-obvious decisions. Users can also live without bit-precise integer support in <random> for a while, so this feature is not part of the MVP.

Wording changes would be needed because <random> specifically supports certain integer types specified in [rand.req.genl], rather than having blanket support for bit-precise integers.

Another issue lies with linear_congruential_engine. This generator performs modular arithmetic, which requires double the integer width for intermediate results. For example, int64_t modular arithmetic is implemented using __int128 in some standard libraries (if available). An obvious problem for bit-precise integers is how modular arithmetic for bit_int<BITINT_MAXWIDTH> is meant to be implemented. We obviously can't just use a wider integer type because none exists. These and other potential design issues should be explored in a separate paper.

5.8. simd support for bit-precise integers

<simd> is one of the few parts in the standard library where the implementation is highly specific to integer widths, at least if high implementation quality is needed.

5.8.1. simd design problems

There are many important questions, such as:

• How do we best optimize simd::vec<bit_int<1>>? that type is effectively a bitset.
• How do we deal with padding bits? Standard integers are typically padding-free, but bit-precise integers are not except for specific sizes.
• What about simd::vec<bit_int<512>> or even greater widths? It seems like this case degenerates into a scalar implementation anyway.

It is not obvious whether design changes are needed to properly support bit-precise integers. Furthermore, adding a naive implementation for e.g. bit_int<1> would result in an ABI break when being replaced with a more efficient "bit-packed" implementation later.

5.8.2. simd design conclusion

Due to these design concerns, I do not consider fullsimd support to be part of the MVP. However, simd support for bit-precise integers is clearly useful, so a compromise is possible: simd support is added only for those bit-precise integers whose width matches a standard integer type.

This means that a simd::vec<bit_int<32>> implementation "piggy-backs" off of an existing simd::vec<int> implementation, assuming int is a 32-bit signed integer. Such limited support is easy to provide.

5.9. valarray support for bit-precise integers

Bit-precise integer support in valarray is required. While the same concerns as with <simd> apply in theory, it is easy to provide a naive implementation, and the implementation in standard libraries is typically naive anyway, including for existing integers.

5.10. Broadening is_integral

Since bit-precise integer types are integral types, obviously, is_integral_v<T> should be true for any bit-precise integer T.

There is a potential concern that existing C++ code constrained using is_integral or integral never anticipated that the templates would be instantiated with huge integers like bit_int<1024>. That is simply a problem we have to live with. The only way to avoid the issue would be to create a taxonomy of integer types that is confusing and inconsistent with C (e.g. by not considering bit-precise integers to be integral types), or to make is_integral_v inconsistent with the term "integral type". Both of these alternatives seem terrible.

5.11. Miscellaneous library support

There are many more standard library parts to which support for bit-precise integers is added. Examples include:

• C headers such as <stdbit.h> and <stdckdint.h> receive the same degree of support as they have in C. This is the obvious design, and any deviation would need to be justified somehow.
• Various utilities such as to_integer and hash receive support for bit-precise integers. It is implausible that support wouldn't be added in the long run, and the support is added by extending the existing blanket support for integers; no wording changes are needed.

5.12. Feature testing

After consulting with some LWG and SG10 experts, I have opted to add only two feature-test macros: one for the core feature, and one for the standard library. While more granular feature-testing could be useful considering that the feature is quite large, there seems to be little enthusiasm for it.

5.13. Passing bit_int into standard library function templates

Unlike standard integers, it is plausible that some bit-precise integers are too large to be passed on the stack, or at least too large to make this the "default option". Nonetheless, all proposed library functions which operate on bit_int should accept bit_int by value.

The reason for having such signatures is that the details of how values are passed into functions are outside the scope of the standard. Since most functions in the standard are not addressable, and since we don't care about keeping the results of reflecting on the standard library stable, the actual overload sets in the library implementation can differ from the declarations in the standard.

Admittedly, having the standard pass all integers by value may give the user the false impression that a bit_int<N> function parameter (with unconstrained N) is idiomatic and harmless, which is problematic. However, it is seemingly the lesser evil, since the alternative is wasting LEWG and LWG time on quality of implementation.

6. Education

Following SG20 Education recommendations at Sofia 2025, this proposal contains guidance on how bit-precise integers are meant to be taught by learning resources.

6.1. Teaching principles

1. Emphasize familiar features. The closest equivalents to std::bit_int and std::bit_uint are std::intN_t and std::uintN_t, respectively.
2. Clearly distinguish std::bit_int from other existing integer types. It should be clarified that std::bit_int is always a distinct type from the std::intN_t aliases, even if it behaves similarly. Furthermore, the major differences are:
   • std::bit_int is not optional (though there exists a maximum width), whereas any std::intN_t may not actually exist.
   • std::bit_int is not subject to integer promotion, unlike any of the existing standard integer types.
   • std::bit_int cannot be used as the underlying type of enumerations.
3. Only reference the _BitInt spelling in a note on C compatibility. _BitInt(N) looks nothing like the class templates that C++ users are used to, and nothing suggests that N is required to be a constant expression. The std::bit_int and std::bit_uint alias templates should be taught first and foremost.
4. Point out potential pitfalls:
   • std::bit_int has a BITINT_MAXWIDTH which is not guaranteed to be any more than 64. The user should be made aware of this portability problem.
   • When writing generic code, the user should be made aware that accepting std::bit_int<N> in a function signature may be problematic. For all they know, std::bit_int<N> could have millions of bits, and this could make the type too large for passing on the stack.

7. Implementation experience

_BitInt, formerly known as _ExtInt, has been a compiler extension in Clang for several years now. The core language changes are essentially standardizing that compiler extension.

8. Impact on the standard

8.1. Impact on the core language

The core language changes essentially boil down to adding the _BitInt type and the wb integer-suffix. This obviously comes with various syntax changes, definitions of conversion rank, addition of template argument deduction rules, etc. The vast majority of core language wording which deals with integers is not affected by the existence of bit-precise integers.

8.2. Impact on the standard library

The impact of adding bit-precise integers to the standard library is quite enormous because there are many parts of the library which already support any integer type via blanket wording. Additionally, bit-precise integer support for various components such as std::to_chars is explicitly added.

Since this proposal does not explicitly remove support for bit-precise integers, support "sneaks" its way in, without any explicit wording changes. For example, use of bit-precise integers in <simd>, <bit>, <valarray>, and many others is enabled.

The addition of bit-precise integers means that (as in the core language), the size_type of various containers may be a bit-precise integer, size_t and ptrdiff_t may be bit-precise integers, etc.

Find a summary of affected library components below. In the interest of reducing noise, the possible changes to container size_types are not listed.

9. Wording

The following changes are relative to [N5014].

9.1. Core

[lex.icon]

In [lex.icon], change the grammar as follows:

Change table [tab:lex.icon.type] as follows:

Change [lex.icon] paragraph 4 as follows:

[basic.fundamental]

Change [basic.fundamental] paragraph 1 as follows:

Change [basic.fundamental] paragraph 2 as follows:

Change [basic.fundamental] paragraph 5 as follows:

[conv.rank]

Change [conv.rank] paragraph 1 as follows:

[conv.prom]

Change [conv.prom] paragraph 2 as follows:

Change [conv.prom] paragraph 5 as follows:

[dcl.type.general]

Change [dcl.type.general] paragraph 2 as follows:

[dcl.type.simple]

Change [dcl.type.simple] paragraph 1 as follows:

Change table [tab:dcl.type.simple] as follows:

Immediately following [dcl.type.simple] paragraph 3, add a new paragraph as follows:

[dcl.enum]

Change [dcl.enum] paragraph 2 as follows:

Change [dcl.enum] paragraph 5 as follows:

Change [dcl.enum] paragraph 7 as follows:

[temp.deduct.general]

Add a bullet to [temp.deduct.general] note 8 as follows:

[temp.deduct.type]

Change [temp.deduct.type] paragraph 2 as follows:

Change [temp.deduct.type] paragraph 3 as follows:

Change [temp.deduct.type] paragraph 5 as follows:

Change [temp.deduct.type] paragraph 8 as follows:

Do not change [temp.deduct.type] paragraph 14; it is included here for reference.

The type of N in the type T[N] is std::size_t.

[Example:

template<typename T> struct S; template<typename T, T n> struct S<int[n]> { using Q = T; }; using V = decltype(sizeof 0); using V = S<int[42]>::Q; // OK; T was deduced as std::size_t from the type int[42]

— end example]

Immediately following [temp.deduct.type] paragraph 14, insert a new paragraph:

Change [temp.deduct.type] paragraph 20 as follows:

[cpp.predefined]

Add a feature-test macro to the table in [cpp.predefined] as follows:

9.2. Library

[version.syn]

Add the following feature-test macro to [version.syn]:

[cstdint.syn]

In [cstdint.syn], update the header synopsis as follows:

Change [cstdint.syn] paragraph 2 as follows:

Change [cstdint.syn] paragraph 3 as follows:

[climits.syn]

In [climits.syn], add a new line below the definition of ULLONG_WIDTH:

Change the synopsis in [climits.syn] paragraph 1 as follows:

[stdbit.h.syn]

Change [stdbit.h.syn] paragraph 2 as follows:

[range.iota.view]

Change [range.iota.view] paragraph 1 as follows:

[alg.foreach]

Change [alg.foreach] for_each_n as follows:

[alg.search]

Change [alg.search] paragraph 5 as follows:

[alg.copy]

Change [alg.copy] paragraph 15 as follows:

[alg.fill]

Change [alg.fill] paragraph 2 as follows:

[alg.generate]

Change [alg.generate] paragraph 2 as follows:

[charconv.syn]

Change [charconv.syn] paragraph 1 as follows:

[charconv.to.chars]

Change [charconv.to.chars] as follows:

[charconv.from.chars]

Change [charconv.from.chars] as follows:

[string.syn]

Change [string.syn] as follows:

If the existing overloads for integral types have been made constexpr through [P3438R0] or a subsequent paper, additionally make the following changes:

[string.conversions]

Change [string.conversions] as follows:

If the existing overloads for integral types have been made constexpr through [P3438R0] or a subsequent paper, additionally make the following changes:

[cmath.syn]

In [cmath.syn], change the synopsis as follows:

[c.math.abs]

Change [c.math.abs] as follows:

[simd.general]

Change [simd.general] paragraph 2 as follows:

[numerics.c.ckdint]

Change [numerics.c.ckdint] as follows:

[atomics.ref.int]

Do not change [atomics.ref.int] paragraph 1; it is provided here for reference:

There are specializations of the atomic_ref class template for all integral types except cv bool. For each such type integral-type, the specialization atomic_ref<integral-type> provides additional atomic operations appropriate to integral types.

[atomics.types.int]

Change [atomics.types.int] paragraph 1 as follows:

10. Acknowledgements

I thank Jens Maurer and Christof Meerwald for reviewing and correcting the proposal's wording.

I thank Erich Keane and other LLVM contributors for implementing most of the proposed core changes in Clang's C++ frontend, giving this paper years worth of implementation experience in a major compiler without any effort by the author.

I thank Erich Keane, Bill Seymour, Howard Hinnant, JeanHeyd Meneide, Lénárd Szolnoki, Brian Bi, Peter Dimov, Aaron Ballman, Pete Becker, Jens Maurer, Matthias Kretz, Jonathan Wakely, Jeff Garland, Ville Voutilainen, Peter Dimov, Luigi Ghiron, and many others for providing early feedback on this paper, prior papers such as [P3639R0], and the discussion surrounding bit-precise integers as a whole. The paper would not be where it is today without hundreds of messages worth of valuable feedback.

11. References