I'm not working on this, but I have some concerns.
Perhaps we should provide them with alias templates with non-_Ugly names, like
template<int N> // or size_t which is consistent with the type of N deduced from T[N]
using bit_int = _BitInt(N);
template<int N>
using bit_uint = unsigned _BitInt(N);
where the keyword
_BitInt doesn't need to go into the C++ standard.
I don't necessarily object to providing a std::bit_int<N> alias in some standard header; but I would very much like to be able
- to use `_BitInt` in C++ programs in the core language, without including any standard headers;
- to use the same syntax for `_BitInt(N)` in both C and C++ (e.g. in header files shared between languages, without adding extra #ifdefs)
- to be able to express `unsigned _BitInt(N)` by putting the token `unsigned` next to the name of the type, instead of by wrapping it in `std::make_unsigned_t` (which again requires including a standard header)
- to save work for the Clang maintainers, who otherwise will feel duty-bound to add extra codepaths just to diagnose the "improper" use of `_BitInt` outside of system headers in C++ mode (even though the compiler will of course support it, and must support it in system headers). Extra codepaths = extra bugs = extra time that could be spent on better things.
For better and worse: Present-day C++ supports exactly one _Camel keyword: `_Pragma`.
Also, it may be desired to deduce N from _BitInt(N) or
unsigned _BitInt(N) (otherwise, it would become hard to implement std::is_integral), which can be achieved by expanding [temp.deduct.type].
I tend to agree that the N should be deducible, but I think it's not 100% obvious. Basically the question is whether _BitInt(N) should act like a composed type
template<int N> using ImitationBitInt = Bit[N]; // deducible
or an opaque mapping onto an infinite number of pre-existing integer types
template<int N> struct ImitationBitInt { using type = Bit[N]; }; // non-deducible
The "opaque mapping" idea isn't completely impossible: Technically, we don't
need `std::is_integral` to be implementable in the core language. Or (leaving N non-deducible) we could introduce a `std::is_bit_int_v<T>` type trait that concentrates all the magic in one place.
But I tend to agree that the N should be deducible.
my $.02,
Arthur