I hadn't thought of the bit-field idea; but I was already going to echo
JeanHeyd's conclusion. Remember that every C++ compiler is also a C
compiler, and therefore will (at some point) support whatever C is doing in
this space, as a conforming extension if nothing else. For example, Clang
already supports in C++ mode:
  using T = _BitInt(256);
  T add(T a, T b) { return a + b; }
It would be a bad idea to force compilers to support two different ways of
doing wide integers — two different overload-resolution hierarchies, two
different sets of promotion rules, etc. etc. — if it can be at all avoided.

However, at the same time, it's true that we did this with std::atomic and
_Atomic. My impression is that the semantics of _Atomic and std::atomic
mutually converged over the next couple of decades: They started out with
the *basic intent* to be compatible, and these days they're *actually*
pretty compatible. So if you're intending the same kind of story for
_BitInt and std::bitint (or whatever), then I suspect that would assuage
*my* concerns, at least.

FWIW, today Clang supports `struct S { _BitInt(256) bf_ : 199; }` in C++
mode, and from my *very* brief testing it seemed to do something sensible.

–Arthur


On Sat, Feb 15, 2025 at 6:37 PM 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>