Bit-precise integers — _BitInt in C++

Contents

1. Introduction

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

2. Design discussion

2.1. Why not make it a library type?

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

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

Furthermore, expressions of type _BitInt can be used as array sizes, in case labels, and any other place where integers but not class types are permitted. A developer would face severe difficulties when porting C code which makes use of these capabilities to C++.

2.1.2. 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. If so, class bit_int is arguably adding pointless bloat.

For example, when an integer division has a constant divisor, like x / 10, it can be optimized to a fixed-point multiplication, which is much cheaper. Performing such an optimization requires the compiler to be aware that a division is taking place, and this fact is lost when division is implemented in software, as a loop which expands to hundreds of IR instructions.

"Frontend awareness" of these operations is also necessary to provide compiler warnings when a division by zero or a bit-shift with undefined behavior is spotted. 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. Another workaround would be an ever-growing set of implementation-specific attributes, but at that point, we may as well make it fundamental.

3. Impact on implementations

4. Impact on the standard

5. Proposed wording

6. References