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.

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.

On Tue, Sep 9, 2025 at 9:39 PM Brian Bi <bbi5291_at_[hidden]> wrote:
>
> I think the rationale is as follows:
>
> We should not deprecate a feature unless we reasonably believe it will be possible to remove it in the foreseeable future
> It is not reasonable to believe that we can remove narrowing implicit conversions to integer types that already exist in C++ any time soon
> Therefore, we should not deprecate such conversions
> However, if we introduce new integer types for which such conversions are illegal from the get-go, we give C++ programmers who wish to avoid such conversions the ability to do so (by opting into using those new types).
>
> --
> Brian Bi