On Tue, Sep 9, 2025 at 9:24 PM Halalaluyafail3 via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > Do we really want 0wb to be a null pointer constant? Note that C++ is
> > already more strict than C for null pointer constants.
>
> C++ allows 0z as a null pointer constant, what's the reason to need to be
> more
> strict in this regard? Note that the reason they were made more strict
> IIRC was
> because templates could create expressions that were conditionally null
> pointer
> constants.
>
> > Shouldn't we take the opportunity to tighten up on implicit
> > conversions for new types instead? And maybe push WG14 to do the same?
>
> I seriously doubt C++ adding extra restrictions on conversions would cause
> WG14
> to change their mind. Consider the following:
>
> bool b=nullptr;
>
> This is invalid in C++, but when C added nullptr it decided to allow it.
> And
> that was a feature C++ already had, it seems even more unlikely it would
> work
> going the other way and adding constraints in C++ to a C feature.
>
> As for why to not try and take the opportunity to add extra restrictions on
> conversions, simply because it makes using existing code with bit-precise
> types
> easier. For example, templated code that uses arbitrary integer types will
> need
> to be reevaluated in order to ensure support for bit-precise types if they
> have
> different restrictions in conversions.
>
> > I would be a lot happier if we limit support for _BitInt to the cases
> > that are actually useful, and try to prevent any (accidental) misuse.
>
> What are the actually useful cases? To me, adding extra restrictions to
> specifically the bit-precise types just seems to add impediments to using
> them
> without actually improving the language in any meaningful way. If you want
> to
> have implicit conversions between floating point types and integer types be
> removed it seems more useful to actually deprecate that. Then, at some
> point in
> the future they could eventually be removed. Just removing it for
> bit-precise
> types will still allow for 99% of accidental floating point to integer
> conversions.
>

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


> On Tue, Sep 9, 2025 at 4:00 PM Christof Meerwald via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Mon, Sep 01, 2025 at 08:02:44PM +0200, Jan Schultke via Std-Proposals
> wrote:
> > > As some of you may already know, I am working on bringing bit-precise
> > > integers (_BitInt) to C++. See a very early draft of the paper here:
> > >
> > > https://isocpp.org/files/papers/D3666r0.html
> >
> > The paper mentions full C comaptibility, but is that really desirable?
> > Shouldn't we take the opportunity to tighten up on implicit
> > conversions for new types instead? And maybe push WG14 to do the same?
> >
> > Do we really want 0wb to be a null pointer constant? Note that C++ is
> > already more strict than C for null pointer constants.
> >
> > And is there a good use case for having implicit conversions from
> > floating point types to _BitInt?
> >
> > I would be a lot happier if we limit support for _BitInt to the cases
> > that are actually useful, and try to prevent any (accidental) misuse.
> >
> >
> > Christof
> >
> > --
> > https://cmeerw.org sip:cmeerw at cmeerw.org
> > mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*