I think we can meet in the middle. We can define the concept of bit-precise integer types in the language, and then have library alias templates to them. _BitInt could remain as a reserved identifier, if we decide that it's too ugly.

Lénárd


On 15 February 2025 23:37:13 GMT, JeanHeyd Meneide via Std-Proposals <std-proposals_at_[hidden]> wrote:
> I would be careful about making std::bit_int a library type. A driving
>reason for this to exist in C is to start using this fairly aggressively in
>bitfields, and many vendors embedded and not have made it clear they want
>to do this as an extension and improve the story for bit-fields in this
>around C. Insofar as I understand it, having std::bit_int as a class
>template would make it very, very difficult to coordinate in this fashion
>without some interesting language surgery to allow this type, specifically,
>in bit-fields. (Imagine similar to the wonky compiler internals to,
>specifically, bless std::byte, but much more thorny.)
>
> One serious additional benefit of not making this a library-driven
>feature as well is that a compiler is allowed to step on the "padding bits"
>of a C _BitInt; a std::bit_int that has to fill the padding bits with
>unused bytes can't reasonably be understood by a normal compiler as having
>those unused bits in class members contain irrelevant padding values, and
>so any clever size optimizations go into the trash without compiler special
>casing or new techniques to mark parts of a structure as containing padding
>bits.
>
> In short: please consider putting this into the language. While the
>functionality can be approximated as a library type, you may run into many
>thorny niche-but-nonetheless-important problems if such information is not
>encoded directly into the compiler.
>
>Sincerely,
>JeanHeyd