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

Arthur, my dude, I have spent dozens of emails across multiple
proposals discussing these ideas over the last few days. You're making
it sound like I'm conceding on bad ideas with no fight. I'm merely
recognizing that there are trade-offs here, it's a contentious point,
and I likely won't convince people until a decision is made in EWG.

If you read the proposal, you would notice that the contentious
decisions are marked with "DECISON:" blocks, but the design of the
proposal is still one that's sticking as closely as possible to the C
semantics.

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

Yeah sure, list initialization played out poorly. I'm not convinced
that constraining implicit conversions is a proper equivalence.

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

As Brian said, _BitInt in C does not have integer promotion, so
neither should the C++ feature. This isn't solving an unrelated
problem.

I think it's fairly reasonable to constrain certain semantics so that
e.g. converting _BitInt to char implicitly would be valid in C, but
not in C++. That's not solving an unrelated problem, but thinking
about whether a permissive C-style _BitInt is better or worse for C++
than a more restrictive one.