On Wed, Sep 10, 2025 at 11:03 AM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

But `_BitInt`, as specified in C, *doesn't promote* even though a standard
integer type of the same width might promote, and I'm sure you're not
advocating *putting promotions back in* when we standardize it in C++ in
order to make it as similar as possible to standard integer types.


>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*