Bit-precise integers
P3666R4

Introduction

C23 now has _BitInt type for N-bit integers (WG14 N2763, N2775):

• implemented by GCC and Clang; max: _BitInt(8'388'608)
• forwarded by EWG to LEWG/CWG for C++29

P3666R3 LEWG in Croydon 2026

POLL: We should prevent library support for _BitInt

SF	F	N	A	SA
5	9	2	3	1

Outcome: Consensus in favor

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

SF	F	N	A	SA
7	4	5	2	0

Outcome: Consensus in favor

POLL: We should provide alias templates for _BitInt […]

SF	F	N	A	SA
0	3	8	3	5

Outcome: Consensus against

POLL: We should provide std::bit_int and std::bit_uint as class templates […]

SF	F	N	A	SA
2	4	8	4	0

Outcome: No consensus

std::is_integral_v<_BitInt(N)>

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

SF	F	N	A	SA
7	4	5	2	0

Outcome: Consensus in favor

• other poll outcomes are implemented, but not this one
• LEWG voted with incomplete information
• here is why …

Intuition

A bit-precise integer is an integer.

• LEWG disagrees
• integer type is an alias for integral type ([basic.fundamental])
• no clear way to avoid obvious teachability problems

Procedural issues

Two schools of thought

1. The type trait simply reports what is an integer type in the core language.
   • LEWG has no design freedom; EWG decides
   • poll outcome is procedurally invalid
2. The type trait is observable behavior, anything else is wording strategy.
   • LEWG gets to decide
   • integer type can be redefined if use sites are updated
   • e.g. std::is_class_v is false for unions (but unions are class types)

P3666R4 type taxonomy — C compatibility

integral types
   ├── signed or unsigned integer types
   │   ├── standard integers: int, unsigned, etc.
   │   ├── extended integers: __int128 etc.
   │   └── bit-precise integers: (unsigned) _BitInt(N)
   ├── character types: char, wchar_t, etc.
   └── bool

• P3666R4 mostly matches C2y taxonomy
• e.g. character types are different
• two radically different taxonomies are harder to learn

std::is_integral is underconstraining

• rationale for poll: existing std::is_integral constraints would change
• surprisingly, std::is_integral_v also matches:
  • char
  • char32_t
  • const volatile bool
  • […]
• users likely expect int, unsigned long, etc. instead
• std::is_integral_v by itself is not a suitable constraint anyway

std::is_integral_v<_BitInt(N)>
is already true in libc++

• (but false in libstdc++)
• this was not mentioned in LEWG
• total reframing of the poll:
  • What should the behavior be in the future?
  • Do we want to change the existing libc++ behavior?
• if LLVM is fine with shipping this behavior, why are we not?
• do we know better?

Most code handles the change fine

• no innate problem with T = _BitInt(N)
• edge case: promotion to int can prevent some UB
• … but also introduce UB (e.g. T = unsigned short)
• problems usually arise only for huge widths

Extended integer types

• integral type has always been arbitrarily extendable
• implementation can add _ExtInt(N) as extended integer type with same properties as _BitInt(N)
• std::is_integral_v<_ExtInt(N)> is true then

Key question:

If the implementation can arbitrarily extend integral type, why can't we extend it with _BitInt?

std::is_integral_v<_BitInt(N)>
is eternal

Key question:

If std::is_integral_v<_BitInt(N)> is false now, can we suddenly make it true later?

Likely answer:

This is our only chance to make it true.

Extending categories of fundamental types

Past:

• character type: char, wchar_t, char8_t, char16_t, char32_t
• floating-point type: float, double, long double, std::bfloat16_t, […], std::float128_t

Future:

• integral type: int, unsigned long, […] _BitInt(N)
• floating-point type: float, […], std::float128_t, std::decimal32_t, std::decimal64_t, std::decimal128_t

The end

• Let's get std::is_integral_v<_BitInt(N)> right!
• Most of remaining of design/wording is obvious consequence.