On Tue, Sep 9, 2025 at 11:03 PM Halalaluyafail3 via Std-Proposals
<std-proposals_at_[hidden]> 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. 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.

Well, the first thing is this: what does `_BitInt` *already* do in C?
We're not speculating on a hypothetical feature. This is largely a
compatibility exercise: making C++ do what C23 can do, possibly with a
C++ coating of paint on it.

So if `_BitInt` supports some operation in C, then the equivalent in
C++ should too. If it explicitly forbids it, then the C++ equivalent
should too.

For example, `_BitInt` doesn't allow integer promotions in C23. So the
C++ version shouldn't either.

That having been said, if we're talking about things for which C
doesn't have an analog, there's no reason to force `_BitInt` to do
what normal integer types do.

No, the language will never be perfect. But that's not a good
justification to keep making the same mistakes due to consistency.
`_BitInt` is not meant to replace integer types; it *should* be a
specialized tool for specialized needs. I'm not even sure that a
bit-precise integer ought to be considered
`std::integral/is_integer_v`.


> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals