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