Hi,

On 2 February 2024 00:53:19 GMT, Franklin Yang via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> 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.

It's a keyword in C, doesn't require any include AFAIK,

>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.

It wouldn't be there for pure C++ code, but for the C + C++ headers of ibraries. We don't need more ifdef __cplusplus here.

It's fine to discourage its use otherwise in purely C++ code.

Cheers,
Lénárd

>
>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