> On Sep 4, 2025, at 9:11 PM, Magnus Fromreide via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> IMHO, C++ should support the keyword and name _BitInt for compatibility with
>> C here. It should /also/ support a C++ style std::bit_int<N> style for
>> people writing C++ code. The two names should refer to the same type -
>> perhaps simply by making _BitInt a pre-defined macro. Any C++ additions to
>> _BitInt (such as, say, specialisations for hash or swap) would be documented
>> for the C++ style name.
>
> C support the use of bit-precise integer types in bit-fields. Both
>
> struct X {
> std::bit_int<4> name : 3;
> };
>
> and
>
> struct X {
> _BitInt(4) name : 3;
> };
>

Ignoring all the other things being discussed, regardless of positions people are taking, this seems a strange thing to permit. I assume it’s just what falls out of having an integral representation, but I feel like it would have been worth making a carveout to disallow this. I’m sure there’s an element of allow _BitInt(32) to be interchangeable with int32_t, but my _understanding_ (which I accept may well be wrong) is that it is not considered the same, in the sense that _BitInt(32)* could not alias int32_t*?

Also to be clear: I am not advocating we diverge from C here, as I think there is value to maintaining compatibility between the languages even if some folk do not, and of course we will be expected to handle C struct definitions no matter what we might say in the standard.

—Oliver