Date: Mon, 1 Sep 2025 15:02:02 -0400
On Mon, Sep 1, 2025 at 2:03 PM Jan Schultke via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hey,
>
> As some of you may already know, I am working on bringing bit-precise
> integers (_BitInt) to C++. See a very early draft of the paper here:
>
> https://isocpp.org/files/papers/D3666r0.html
>
> The debate over whether _BitInt should be a fundamental type or
> library type has been largely settled, however there are two other
> contentious points:
>
> 1. C does not allow _BitInt(1); should C++ to make generic programming
> more comfortable?
> 2. Should the _BitInt keyword exist in C++? I currently propose to
> have it, mainly because it inevitably will exist as a compiler
> extension or compatibility macro, and it seems pointlessly
> user-hostile not to just standardize existing practice.
>
> If you have some early feedback, especially feedback on these two
> points, that would be appreciated.
>
> You should expect the finished paper to be in the September mailing.
The first question I have with something like `_BitInt(N)` is... how
does `N` work? `bit_int<N>` works in a way that we understand in C++
because... it's a template. It looks like a type generated via a
template. `_BitInt(N)` looks like a function call. For `bit_int<N>`,
`N` is a template argument. Therefore it must be a constant
expression.
But for `_BitInt(N)`... what is `N` allowed to be? C++ does have
`consteval` functions that forbid taking non-constant expression
parameters, but `_BitInt` is *not* a function call. It's a thing that
looks like a function call that results in a type? While C++ may
eventually have something like that post-reflection, it's not a normal
C++ thing right now.
I know it's inherited from C, which doesn't have templates. But it's
very bizarre in a C++ context, especially since C++ *already has*
something that works like that. It creates a language wart, all in the
name of backwards compatibility. Also, I'm not saying that this would
be a problem for parsers; it's just a visual ugliness that's very
foreign to C++ mechanisms.
<std-proposals_at_[hidden]> wrote:
>
> Hey,
>
> As some of you may already know, I am working on bringing bit-precise
> integers (_BitInt) to C++. See a very early draft of the paper here:
>
> https://isocpp.org/files/papers/D3666r0.html
>
> The debate over whether _BitInt should be a fundamental type or
> library type has been largely settled, however there are two other
> contentious points:
>
> 1. C does not allow _BitInt(1); should C++ to make generic programming
> more comfortable?
> 2. Should the _BitInt keyword exist in C++? I currently propose to
> have it, mainly because it inevitably will exist as a compiler
> extension or compatibility macro, and it seems pointlessly
> user-hostile not to just standardize existing practice.
>
> If you have some early feedback, especially feedback on these two
> points, that would be appreciated.
>
> You should expect the finished paper to be in the September mailing.
The first question I have with something like `_BitInt(N)` is... how
does `N` work? `bit_int<N>` works in a way that we understand in C++
because... it's a template. It looks like a type generated via a
template. `_BitInt(N)` looks like a function call. For `bit_int<N>`,
`N` is a template argument. Therefore it must be a constant
expression.
But for `_BitInt(N)`... what is `N` allowed to be? C++ does have
`consteval` functions that forbid taking non-constant expression
parameters, but `_BitInt` is *not* a function call. It's a thing that
looks like a function call that results in a type? While C++ may
eventually have something like that post-reflection, it's not a normal
C++ thing right now.
I know it's inherited from C, which doesn't have templates. But it's
very bizarre in a C++ context, especially since C++ *already has*
something that works like that. It creates a language wart, all in the
name of backwards compatibility. Also, I'm not saying that this would
be a problem for parsers; it's just a visual ugliness that's very
foreign to C++ mechanisms.
Received on 2025-09-01 19:02:19