Date: Fri, 05 Sep 2025 09:27:35 +0100
On 5 September 2025 05:11:49 BST, Magnus Fromreide via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Thu, Sep 04, 2025 at 02:59:48PM +0200, David Brown via Std-Proposals wrote:
>> On 04/09/2025 14:31, Yexuan Xiao via Std-Proposals wrote:
>> >
>> > A few years ago when I learned that _Bitint was included in C23, I also
>> > thought about this issue many times. My conclusion is that implementing
>> > it using a class template is really not a good idea, and using a
>> > built-in type would make things easier for its users. However, I believe
>> > that using a library to address the surprising results of integer
>> > promotions in bitwise operations is better than using _Bitint.
>> > Additionally, I’m not a fan of the underscore in the name bit_int.
>> >
>>
>> The name _BitInt is from C, where there are no namespaces - so new keywords
>> generally have to be taken from a reserved identifier space and thus are
>> typically underscore and then a capital letter.
>>
>> IMHO, C++ should support the keyword and name _BitInt for compatibility with
>> C here. It should /also/ support a C++ style std::bit_int<N> style for
>> people writing C++ code. The two names should refer to the same type -
>> perhaps simply by making _BitInt a pre-defined macro. Any C++ additions to
>> _BitInt (such as, say, specialisations for hash or swap) would be documented
>> for the C++ style name.
>
>C support the use of bit-precise integer types in bit-fields. Both
>
>struct X {
> std::bit_int<4> name : 3;
>};
>
>and
>
>struct X {
> _BitInt(4) name : 3;
>};
>
>looks unfamiliar.
>
>The _BitInt(N) syntax have the advantage that
>
>unsigned _BitInt(N)
>
>looks reasonable whereas
>
>unsigned std::bit_int<N>
>
>looks quite odd - bit_int can't be a library class unless it is very magic,
>and it can't be a typedef without a rule change on how signed/unsigned binds.
>
>This could obviously be solved with an
>
>std::ubit_int<N>
>
>but it still leaves the bit-field case as an additional oddity with the
>library-looking solution as no other library types are allowed.
<cstdint> types are also allowed, std::bit_int<N> is also an alias. C++ also allows enums for bit-fields.
>
>==
>
>I do think it could be nice if one could avoid having to repeat the size when
>writing
>
>struct X {
> _BitInt(N) name : N;
>};
>
>maybe
>
>struct X {
> _BitInt name : N; // Takes the width from the bit-field
>};
>
>but I admit that it is such a niche use case that it can wait for some
>future standardization round.
>
>/MF
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>On Thu, Sep 04, 2025 at 02:59:48PM +0200, David Brown via Std-Proposals wrote:
>> On 04/09/2025 14:31, Yexuan Xiao via Std-Proposals wrote:
>> >
>> > A few years ago when I learned that _Bitint was included in C23, I also
>> > thought about this issue many times. My conclusion is that implementing
>> > it using a class template is really not a good idea, and using a
>> > built-in type would make things easier for its users. However, I believe
>> > that using a library to address the surprising results of integer
>> > promotions in bitwise operations is better than using _Bitint.
>> > Additionally, I’m not a fan of the underscore in the name bit_int.
>> >
>>
>> The name _BitInt is from C, where there are no namespaces - so new keywords
>> generally have to be taken from a reserved identifier space and thus are
>> typically underscore and then a capital letter.
>>
>> IMHO, C++ should support the keyword and name _BitInt for compatibility with
>> C here. It should /also/ support a C++ style std::bit_int<N> style for
>> people writing C++ code. The two names should refer to the same type -
>> perhaps simply by making _BitInt a pre-defined macro. Any C++ additions to
>> _BitInt (such as, say, specialisations for hash or swap) would be documented
>> for the C++ style name.
>
>C support the use of bit-precise integer types in bit-fields. Both
>
>struct X {
> std::bit_int<4> name : 3;
>};
>
>and
>
>struct X {
> _BitInt(4) name : 3;
>};
>
>looks unfamiliar.
>
>The _BitInt(N) syntax have the advantage that
>
>unsigned _BitInt(N)
>
>looks reasonable whereas
>
>unsigned std::bit_int<N>
>
>looks quite odd - bit_int can't be a library class unless it is very magic,
>and it can't be a typedef without a rule change on how signed/unsigned binds.
>
>This could obviously be solved with an
>
>std::ubit_int<N>
>
>but it still leaves the bit-field case as an additional oddity with the
>library-looking solution as no other library types are allowed.
<cstdint> types are also allowed, std::bit_int<N> is also an alias. C++ also allows enums for bit-fields.
>
>==
>
>I do think it could be nice if one could avoid having to repeat the size when
>writing
>
>struct X {
> _BitInt(N) name : N;
>};
>
>maybe
>
>struct X {
> _BitInt name : N; // Takes the width from the bit-field
>};
>
>but I admit that it is such a niche use case that it can wait for some
>future standardization round.
>
>/MF
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-09-05 08:27:45