> 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. If for example a new type
> long long long were to be added should we also try and disable some conversions
> specifically for it? Maybe we could also add extra rules to the declaration
> specifiers to prevent wacky stuff like long unsigned long int long.

Note that the topic of implicit conversions is discussed in great
detail here, and marked as a contentious decision.
https://isocpp.org/files/papers/D3666r0.html#permissive-implicit-conversions

A large number of other respondents said they'd want the implicit
conversions to be more restrictive, so there's a good chance it will
happen. 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.

A new kind of specifier that makes integers more strict may not find
favor because it makes the system even more complicated, and at least
for _BitInt, we don't technically need such a bifurcation.

> My point being: instead of trying to design new types to be perfect, just
> understand that the language isn't perfect and probably won't be. If every new
> feature is an opportunity to fix some minor issue then adding anything new will
> be an uphill battle to convince everyone that it's perfect. Also, every fix is a
> new inconsistency in the language. For example, imagine if every new container
> had to use the name is_empty instead of empty to check if the container is
> empty. is_empty is certainly a better name than empty, but it would make generic
> code using is_empty/empty much more cumbersome.

The generic code argument may be the most convincing C++-internal
argument that I have against restricting implicit conversions. See
https://isocpp.org/files/papers/D3666r0.html#difficult-special-cases
(the example with div_ceil).