Bit-precise integers

Contents

1. Revision history

1.1. Changes since R3

During the 2026-03 meeting in Croydon, both EWG and LEWG saw the paper. EWG had only the following poll:

Forward P3666R3 to CWG and LEWG for C++29

SF	F	N	A	SA
17	29	3	2	0

Result: strong consensus in favor

The following changes were made based on feedback from both groups (where the design changes are all to the library part, since EWG forwarded with no changes):

• mentioned the auto deduction case in example in §4.9. Template argument deduction (no design change, just more discussion that matches the wording)
• added discussion on §4.11. Padding in _BitInt
• included LEWG poll results from the 2026-03 Croydon meeting and called for relitigation in §5.2. Broadening is_integral
• removed the proposed std::bit_int and std::bit_uint alias templates
• removed all proposed library overloads for _BitInt, reducing library support to the bare minimum
• removed the section on Education and Teaching principles; it no longer added value because _BitInt is obviously a C compatibility feature, and this is evident from other sections of the paper (and the keyword) already
• mentioned that [N3705] has been adopted into C2y and rephrased parts of the paper accordingly
• rebased §8. Wording on [N5032] with the changes from the Croydon motions applied
• fixed various editorial problems
• massively overhauled wording in §8.2. Library to prevent _BitInt support

1.2. Changes since R2

• mentioned that [N3747] has been approved by WG14 for C2y
• removed std::simd support
• removed std::atomic support
• removed mentions of P3438R0 because to_string is now constexpr
• removed changes to [utility.intcmp] because these are no longer necessary after editorial pull request #8616 was merged
• rebased §8. Wording on [N5032]

1.3. Changes since R1

• added SG22 and SG6 poll results to §4. Core design
• changed the suggested alternative BITINT_MAXWIDTH in §4.8. Raising the BITINT_MAXWIDTH from 65'535 to 32'767
• expanded section on naming of the alias template after SG22 feedback
• added section on preserving integer class types and corresponding wording changes
• fixed missing return types in proposed abs overload and throughout the paper
• expanded section on passing _BitInt in functions with an observation about return types
• added §5.4. The problem of representing widths as int
• added section on library policy for accepting bit-precise integers in templates, and applied the proposed policy to std::abs overload for bit-precise integers
• updated reference from [N3699] to [N3747]
• also added abs overloads to <cstdlib>, instead of just <cmath>
• added changes to [utility.intcmp] (adding support to cmp_less was already intended, but potentially requires wording due to weird choice of constraints)

1.4. Changes since R0

• updated §4.5. _BitInt(1) following the publication of [N3699]
• added §5.3. make_signed and make_unsigned and corresponding wording changes in § [meta.trans.sign]
• permitted bit-precise integers as underlying types of enumerations as standardized in C2y by [N3705]; see §4.3. Underlying type of enumerations and § [dcl.enum]
• further changed § [conv.prom] wording, taking promotion of enumerations with underlying bit-precise integer type into account
• added § [diff.lex] Annex C entry for the difference in the type of 0wb
• various minor wording tweaks and added notes
• converted green notes into aqua "editor's notes" to more clearly distinguish them from wording changes

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. This effort has now converged on a C compatibility design based on fundamental types.

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

3. Motivation

3.1. Computation beyond 64 bits

Computation beyond 64 bits, such as with 128-bit integers, is immensely useful. A large amount of motivation for 128-bit computation can be found in [P3140R0]. Computations in cryptography, such as 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 future 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 a 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.

The first of these points was discussed in great detail in SG22 and SG6, and has unanimous support from both groups; feedback from SG22 was given 2025-10-09 during a telecon:

/Poll/: Do you agree with the author's position on fundamental types being better than class template for _BitInt>?
Any objections to unanimous consent? /None/

/Poll/: Do you agree with allowing 0wb = _BitInt(1) and enum E : _BitInt(N), assuming C adopts N3699 and N3705?
Any objections to unanimous consent? /None/

/Poll/: Do you agree with keeping UB on signed integer overflow for _BitInt?
Any objections to unanimous consent? /None/

/Poll/: Do you agree that WG21 keep all implicit conversions for _BitInt?
Any objections to unanimous consent? /None/

/Poll/: Do you agree that WG21 keep the lower limit on the value of BITINT_MAXWIDTH from C?
Any objections to unanimous consent? /None/

/Poll/: Do you agree that WG21 should add a _BitInt keyword?
Any objections to unanimous consent? /None/

[…]

Group agrees that we want to pursue compatibility between C and C++ with regards to _BitInt

Both directions mentioned in that poll have since been adopted by C2y, via [N3747] and [N3705].

SG6 had concerns regarding the standard library impact of bit-precise integers, but agreed with the core design strategy during the Kona 2025 meeting:

POLL: Let _BitInt have the exact same semantics as in C.

SF	F	N	A	SA
7	2	0	0	0

• Author Position: SF
• Outcome: Strong consensus in favor

EWG then reaffirmed every decision with resounding consensus during the 2026-03 Croydon meeting:

Forward P3666R3 to CWG and LEWG for C++29

SF	F	N	A	SA
17	29	3	2	0

Result: strong consensus in favor

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. LEWG is not convinced that a library type should be pursued

During the 2026-03 Croydon meeting, the following poll was taken:

POLL: We should provide std::bit_int and std::bit_uint as class templates (not necessarily as part of P3666)

SF	F	N	A	SA
2	4	8	4	0

Author's Position: WA
Outcome: No consensus

4.1.2. 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.3. 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.4. 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.5. 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.6. Tiny integers are useful in C++

In some cases, tiny _BitInt types may be useful as the underlying type of an enumeration:

By using _BitInt(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.7. 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 unsigned _BitInt(N) is quite appealing.

If _BitInt(N) was instead surfaced only through 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 that class type. These kinds of deduction rules may be shutting the door on this mechanism forever.

4.1.8. 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.9. 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 not 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 is 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. When the bit_int alias template was still proposed, I considered this a "C compatibility spelling" rather than the preferred one which is taught to C++ developers. Now, it is the only spelling of bit-precise integers in this paper, which should be motivation alone.

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 raise 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; the keyword spelling should be standardized for interoperability.

The _BitInt spelling is useful for writing C/C++-interoperable code, and C compatibility is an important design goal.

Even if compatibility macros exist in some code bases, the proposal itself should standardize the keyword spelling. 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 not valid C23, but is valid in C2y following acceptance of [N3705].

There is no obvious reason why _BitInt must not be a valid underlying type, neither in C nor in C++. For C++, it seems better to simply allow bit-precise integers in this context because it is useful; see §4.1.6. Tiny integers are useful in C++.

Also note that as adopted in [N3705], bit-precise integers should only be the underlying types of enumerations when the user explicitly specifies this with : _BitInt(N):

As adopted in [N3705] and as in the case of bit-precise bit-fields, integer promotion should not take place for enumerations whose underlying type is bit-precise. If the implementation-defined underlying type of enumerations could be chosen to be bit-precise, this would make it implementation-defined whether integer promotion takes place, by proxy. It would also be a compatibility pitfall; C requires bit-precise underlying types to be specified explicitly, so any choice the implementation makes could interfere with future standardization.

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 require two's complement representation for signed integers). This is an irregularity that could make generic programming harder in C++.

However, this restriction is being lifted in C2y; see [N3747] "Integer Sets, v5". That proposal has been approved but not yet merged into the C2y draft at the time of writing. It makes _BitInt(1) a valid type, and 0wb is changed to be of type _BitInt(1) rather than _BitInt(2). It 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.

This revision keeps implicit conversions permissive. If desired, conversions described in §4.7.3. Picking some low-hanging fruits can still be restricted in a follow-up paper.

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 be 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, 32'767, 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 are 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.
• 32'767. 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 32767 is sufficiently large, even in the next few years. Any more than 32767 becomes problematic for the standard library because int is no longer capable of representing the width on 16-bit platforms; this breaks functions such as std::popcount (which returns int). Major design adjustments would be needed to address this problem.

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.

This behavior is part of the core design, and it would be quite surprising to users if such deduction was not possible. If deducing N from std::array<T, N> is possible, why would it not be possible to deduce N from _BitInt(N)?

One thing deliberately not allowed is:

This shorthand construct (which is similar to class template argument deduction) is not part of the MVP and if desired, should be proposed separately.

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.

4.11. Padding in _BitInt

It is worth mentioning that _BitInt types may have padding bits, which the implementation can avoid for standard integer types by choosing padding-free widths for them. This is a known fact, and there is no desire to prohibit _BitInt widths that would have padding bits.

A possible future direction could be to mandate sign extension for those padding bits. The standard currently does not mandate padding bits to have specific values in most cases, but that may be useful for _BitInt.

The problem with such a guarantee is that C does not provide it, so when calling an extern "C" function that takes e.g. _BitInt(3)* as a parameter, it would be impossible for a C++ program to guarantee that the padding bits have been correctly set by the C program. This guarantee can only be provided by C and C++ in tandem, is fairly ambitious, requires ABI changes, and needs to be proposed separately.

5. Library design

In summary, the design for the standard library is to support _BitInt where C already supports it, and to support it in <type_traits>. Anywhere else, support is prevented.

5.1. Preventing library support for _BitInt

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. This happens because bit-precise integers are proposed to be signed and unsigned integer types, so they would be supported by any facility that supports integer types (e.g. <bit>).

Even if the wording effort to support bit-precise integers is minimal in some cases, and even if the implementation effort boils down to adjusting a template constraint, such implicit _BitInt support results in an explosion of the test matrix. For example, std::to_chars may be implemented generically for all integer types, but tests still need to be written to ensure that it works for any _BitInt(N). Furthermore, R3 of this paper hit several design problems, like whether to still pass huge _BitInt by value and how to extend functions like std::to_chars or std::to_string that are not templates in the standard library, but overload sets of non-template functions. Trying to word and implement support for _BitInt all in one paper is simply too much.

LEWG addressed this concern as follows:

POLL: We should prevent library support for _BitInt

SF	F	N	A	SA
5	9	2	3	1

Outcome: consensus in favor

Since LEWG voted to prevent library support for bit-precise integers, we must alter the constraints of various library components to disallow bit-precise integers. To be clear, this does not mean that we prevent std::vector<_BitInt(N)> or anything else that works generically for copyable types, movable types, etc. Such a restriction would be totally toothless anyway because it can be bypassed by wrapping _BitInt in a struct. Only numeric constraints are adjusted.

The interesting question is where we do support bit-precise integers despite the LEWG vote:

• std::is_integral_v<_BitInt(N)> is true, directly contradicting an LEWG poll
• std::make_signed and std::make_unsigned support bit-precise integers
• std::numeric_limits<_BitInt(N)> is specialized
• <cmath> functions support bit-precise integers as arguments
• <stdbit.h> functions support bit-precise integers in those cases where C23 supports them too

5.2. Broadening is_integral

One controversial aspect of this paper is that std::is_integral_v<_BitInt(N)> is proposed to be true. LEWG voted for the opposite during the 2026-03 Croydon meeting:

POLL: std::is_integral_v<_BitInt(N)> should be false

SF	F	N	A	SA
7	4	5	2	0

Outcome: consensus in favor

This decision was motivated by the fact that otherwise, large amounts of existing code (not just the standard library, but also user code) would implicitly opt into supporting bit-precise integers, despite never being written with that intent. It is even theoretically possible that this results in correctness regression due to instantiating templates with e.g. _BitInt(1) and running into signed integer overflow that would have been prevented by promotion to int.

Nonetheless, this poll result caused widespread backlash from members of the committee, Clang implementers, and the C++ community at large. Some described the decision as absurd. There are also many practical problems not discussed during the LEWG session which likely would have prevented consensus from being reached.

5.2.1. Reasons for making std::is_integral_v<_BitInt(N)> true

1. First and foremost, it is intuitive for bit-precise integers to be integral types. This is what users expect.
2. A substantial amount of committee members don't believe LEWG is entitled to a decision on this type trait in the first place. That is because the type trait arguably just exposes the fact that _BitInt is an integral type within the core language, so only EWG, not LEWG can decide the result of std::is_integral; LEWG does not decide what is an integral type in the core language. I personally don't believe that LEWG is powerless in this regard, but the LEWG decision does cause procedural controversy.
3. Classifying _BitInt as an integral type is symmetrical with the taxonomy of integer types in C, where bit-precise integer types are integer types.
4. Any code exclusively constrained on std::is_integral_v is likely under-constrained anyway because it opts into char32_t, const volatile bool, and other types that might not match the user's expectation of integral types. _BitInt would make this problem worse, but it does not create a new problem.
5. libc++ already makes std::is_integral_v<_BitInt(N)> true, so what LEWG wants is silently altering the behavior of existing traits. If LLVM implementers have already shipped this behavior in production code, despite the potential impact on code constrained on std::is_integral_v, why is LEWG effectively claiming it's not feasible to be shipped due to user impact?
6. For the most common use cases of bit-precise integers, such as _BitInt(128), there really isn't a problem caused by implicit support in the standard library or in third-party code. In fact, std::is_integral_v<__int128> has already been decided to be true by libstdc++ and libc++, despite the fact that this could break some third-party code that assumes that integers are no wider than 64 bits and no wider than std::intmax_t. The real problems arise only for small signed bit-precise integers such as _BitInt(1) and for huge bit-precise integers such as (possibly unsigned) _BitInt(32'768).
7. Making std::is_integral_v<_BitInt(N)> false is ineffective when considering that by design, the category of integral types has always been extendable using extended integer types. These are not compiler extensions, but rather an open set of optional types that can even be exposed using aliases such as std::int128_t. Even more extremely, the implementation can decide to add a set of extended integer types such as _ExtInt(N) with essentially identical behavior to _BitInt(N), and the standard would require std::is_integral_v<_ExtInt(N)> to be true. In fact, _ExtInt(N) is currently an alternative spelling for _BitInt(N) in Clang. It would be inconsistent to say it's fine for an arbitrary open set of implementation-specific types to be integral while saying that this is not fine for _BitInt(N).
8. If _BitInt(N) was to receive more standard library support in the future to a point where std::is_integral_v<_BitInt(N)> being false becomes undesirable from LEWG's perspective, it would be a breaking change to make it true later. We can decide to make it whatever we want right now, but this decision is likely irreversible. In the long term, it would make the language design terribly confusing if _BitInt had extensive core language and standard library support, but was not considered an integral type. This is the worst possible design outcome.
9. C++ has always reserved the right to extend type sets and continues to do so. For example, the set of floating-point types was extended to include extended floating-point types such as std::float128_t and std::bfloat16_t, which could also break user expectations regarding floating-point formats. It is also not unlikely that decimal floating-point types will receive a standard alias in the future, such as std::decimal64_t to match _Decimal64 in C. Are we then going to say that decimal floating-point types are not floating-point types?! Note that the implementation can already provide _Decimal64 as an extended floating-point type right now, so this situation is exactly the same as with providing _ExtInt(N) as an extended integer type: it can technically be done already without being classified as a compiler extension, and the type traits match the user expectations in that case.

5.2.2. Conclusion

Given the above reasons, I cannot with good conscience support the LEWG decision to make std::is_integral_­v<_BitInt(N)> false. It requires relitigation, especially since much of the rationale above was not discussed in Croydon, such as the existing libc++ behavior.

5.3. make_signed and make_unsigned

To prevent breaking existing code, the behavior of make_signed and make_unsigned needs to be made future-proof:

The rank of unsigned int is greater than the rank of unsigned _BitInt(32) (assuming those have the same width; see [conv.rank]). Therefore, make_unsigned_t would need to be unsigned _BitInt(32), since it produces ([meta.trans.sign])

unsigned integer type with smallest rank ([conv.rank]) for which sizeof(T) == sizeof(type)

Furthermore, the current wording would give the user an implementation-defined type in the following scenario:

make_signed_t<E> could be either _BitInt(32) or an extended integer type with lower conversion rank than _BitInt(32). However, for simplicity, make_signed and make_unsigned should always produce a bit-precise integer type when they are fed a bit-precise integer type or an enumeration whose underlying type is a bit-precise integer.

Overall, make_signed can be made future-proof with the following set of rules:

• For signed integers and unsigned integers, it does the "obvious thing".
• For types whose underlying type is a bit-precise integer, it behaves like make_signed_t<underlying_type_t<T>>. This only affects enumeration types, since integral types like char32_t are currently specified not to have a bit-precise underlying type.
• For any other integral type (char32_t, other enumerations, etc.), it denotes the smallest standard or extended signed integer type that fits that integral type.

make_unsigned should behave correspondingly.

5.4. The problem of representing widths as int

A pre-existing and prolific issue in the C++ standard library is the use of int to represent properties of integers, such as

• int std::numeric_limits::digits or
• int std::popcount(T).

This has never been a practical issue before, it is now theoretically possible that an implementation may want to provide _BitInt(32'768) or wider. int is only guaranteed to have the range of a 16-bit signed integer, so it may not be able to represent such huge widths.

The easiest solution is to ignore the problem; this is proposed. It would require substantial design changes to <limits> to fix the issue. Furthermore, the practical utility of _BitInt(32'768) and wider is somewhat questionable, especially on 16-bit architectures (which are typically embedded architectures). On 32-bit architectures and above, int is typically 32-bit, so this problem doesn't exist.

5.5. 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.6. Preserving integer-class types

Another very similar wording issue to the one in the previous section arises for the so-called "integer-class types" in the standard library, in [iterator.concept.winc] paragraph 3. Signed-integer-like types are either signed integral types, or signed-integer-class types. Integer-class types are required to be wider than every integral type of the same signedness, so introducing bit-precise integers such as _BitInt(128) means that e.g. Microsoft's std::_Signed128 is no longer an integer-class type, and may no longer be used in ranges::iota_view.

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

We don't need to explicitly disallow this; it is effectively disallowed because the lack of _BitInt support in the standard library would result in a dysfunctional implementation if size_t, ptrdiff_t, or any size_types were bit-precise integers.

5.8. 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.9. 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 support all integer 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.10. Note on alias templates for _BitInt

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

When compiling using Clang and libstdc++, one gets virtually the proposed behavior. That is, just the core language feature, with minimal standard library support.

7. Impact on the standard

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

7.2. Impact on the standard library

As explained in §5. Library design, various constraints are added throughout the standard library to prevent support for bit-precise integers.

8. Wording

The following changes are relative to [N5032] with the changes from Croydon motions applied.

8.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 3 as follows:

Change [conv.prom] paragraph 4 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 5 as follows:

Change [dcl.enum] paragraph 7 as follows:

[temp.deduct.general]

Add a bullet to [temp.deduct.general] paragraph 11 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:

[diff.lex]

In [diff.lex], add a new entry:

8.2. Library

[allocator.requirements.general]

Change [allocator.requirements.general] as follows:

[version.syn]

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

[support.types.byteops]

Change [support.types.byteops] as follows:

[cstdint.syn]

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:

[intseq.intseq]

Change [intseq.intseq] as follows:

[meta.trans.sign]

Change table [tab:meta.trans.sign] as follows:

[utility.intcmp]

Change [utility.intcmp] as follows:

[bit.byteswap]

Change [bit.byteswap] as follows:

[bit]

Change the Constraints element attached to each of the function templates has_single_bit, bit_ceil, bit_floor, bit_width, rotl, rotr, countl_zero, countl_one, countr_zero, countr_one, and popcount as follows:

[stdbit.h.syn]

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

[container.reqmts]

Change [container.reqmts] as follows:

[mdspan.extents.overview]

Change [mdspan.extents.overview] as follows:

[mdspan.sub.overview]

Change [mdspan.sub.overview] paragraph 2, [mdspan.sub.overview] paragraph 3, and [mdspan.sub.overview] paragraph 4 as follows:

[mdspan.sub.range.slices]

Change [mdspan.sub.range.slices] as follows:

[iterator.concept.winc]

Change [iterator.concept.winc] as follows:

[iterator.iterators]

Change [iterator.iterators] paragraph 2 as follows:

[common.iter.types]

Change [common.iter.types] paragraph 1 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:

[numeric.ops.gcd]

Change [numeric.ops.gcd] as follows:

[numeric.ops.lcm]

Change [numeric.ops.lcm] as follows:

[numeric.ops.midpoint]

Change [numeric.ops.midpoint] as follows:

[numeric.sat.func]

Change the Constraints element underneath all function templates in [numeric.sat.func] as follows:

[numeric.sat.cast]

Change [numeric.sat.cast] as follows:

[charconv.syn]

Change [charconv.syn] paragraph 1 as follows:

[format.formatter.spec]

Change [format.formatter.spec] paragraph 2, bullet 3 as follows:

[cmplx.over]

Change [cmplx.over] paragraph 2 as follows:

Change [cmplx.over] paragraph 3 as follows:

[rand.req.seedseq]

In [tab:rand.req.seedseq], change the Pre-post-condition column corresponding to S::result_type as follows:

[rand.req.urng]

Change [rand.req.urng] paragraph 3 as follows:

[rand.util.seedseq]

Change [rand.util.seedseq] as follows:

[cmath.syn]

[simd.expos]

Change [simd.expos] as follows:

[simd.expos.defn]

Immediately following the declaration of deduced-vec-t, add the following declaration:

[simd.mask.overview]

Change [simd.mask.overview] as follows:

[simd.mask.ctor]

Change [simd.mask.ctor] as follows:

[numerics.c.ckdint]

Change [numerics.c.ckdint] as follows:

[time.duration.general]

Change [time.duration.general] paragraph 2 as follows:

[stream.types]

Change [stream.types] as follows: