On Tue, Jan 30, 2024 at 11:02 PM F. v.S. via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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