> 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)
I’m not sure that’s ideal as far as usage or implementation goes. Templates are so much more natural in this scenario (but they don’t have them in C), and implementing a macro (which I presume _BitInt(N) is) as an alias for a template is easy, but not vice versa.
The _BitInt underscore-pascal case also doesn’t feel quite “C++-like” and rather as a C hack (_Atomic, _Bool, _Complex, _Static_assert, etc). C++’s own syntax should be prioritized over compatibility with C, and some C code already doesn’t work with C++ (previous examples as well as the notorious implicit void* conversion). C and C++ are slowly diverging in some sense.
 
Those are my two cents anyways.
 
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Arthur O'Dwyer via Std-Proposals
Sent: Wednesday, January 31, 2024 6:50 AM
To: std-proposals_at_[hidden]
Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Subject: Re: [std-proposals] Bit-precise integers
 
On Tue, Jan 30, 2024 at 11:02 PM F. v.S. via Std-Proposals <std-proposals_at_[hidden] <mailto: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