On Wed, Sep 10, 2025 at 12:07 AM Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Halalaluyafail3 wrote:

> > I understand that it's unlikely that such conversions will be removed.
> However,
> > I still think it's a bad idea to try and do this. _BitInt isn't meant to
> be a
> > replacement for the existing integer types, which it seems like you're
> > suggesting by saying programmers can opt into using these new types.
> They're
> > meant to complement the existing set of integer types. Trying to fix
> some of the
> > unfortunate design decisions every time a new feature gets added is not
> that
> > helpful and causes more problems than it is worth IMO. [...]
>
> [...]
> I don't buy the rationale of "_BitInt isn't meant to be a
> replacement for the existing integer types". It wasn't originally
> designed this way, but there's no reason why it couldn't be a
> replacement in C++ (at least in most situations), and a lot of people
> are interested in using it this way.
>
> It certainly doesn't make my job easier when other people try to "just
> fix all problems with integers real quick" while we're adding _BitInt
> to C++, but oh well.
>

As the author, it's your *job* to push back against bad ideas. If you say
"oh well" and put bad ideas into your proposal, those bad ideas might get
into the Standard (with your name on them).

I strongly agree with Halalaluyafail3's comment (and Jason's). We've seen
exactly this dynamic play out before with uniform initialization.
Originally it was "We need a consistent way to initialize `pair<int,int>`,
`array<int,3>`, and `vector<int>`." But then we threw in "just fix a bunch
of problems real quick" — notably, curly-brace initialization forbids
narrowing conversions. And suddenly we had a bunch of pedagogues in the
C++11 era saying "Use curly braces for all kinds of initializations
*because* it may forbid unwanted narrowing conversions." So then people (1)
have to worry about whether a narrowing conversion in their context is
always unwanted; (2) are encouraged to use `{}` even in contexts (like
generic code) where it Does The Wrong Thing in some other dimension — e.g.
it prefers initializer-list constructors.

So we end up making C++ into a sort of constraint-satisfaction puzzle,
where some syntaxes have one subset of desirable features, some syntaxes
have another (overlapping but distinct) subset, and so on; and people end
up choosing syntaxes/tools/types based on what features (they've heard)
they need, and being frustrated when the combination of features they
*really* (think they) need isn't available in any *single* syntax/tool/type.

That is: _BitInt(N) should be an integer type whose *defining feature* is
that it's N bits wide. Programmers should use it when they could just as
well have used an integer type except that they need it to be *N bits wide*.
It shouldn't have any extraneous features.
If we think there's a general problem with integer promotion, we should
tackle that in a different paper, that addresses *that* problem across all
integer types *simultaneously*.

–Arthur