If an implementation chooses not to implement nullptr as 0, then it
will not advertise pointers as trivially value initializable.

On Mon, 2025-06-09 at 21:49 +0200, Sebastian Wittmeier via Std-
Proposals wrote:
>
> There is no guarantee that nullptr is represented as 0x0.
>
> > -----Ursprüngliche Nachricht-----
> > Von: Avi Kivity via Std-Proposals <std-proposals_at_[hidden]>
> > Gesendet: Mo 09.06.2025 21:22
> > Betreff: Re: [std-proposals] ABI breaks
> > An: Ville Voutilainen <ville.voutilainen_at_[hidden]>;
> > CC: Avi Kivity <avi_at_[hidden]>; std-proposals_at_[hidden];
> >
> > On Mon, 2025-06-09 at 16:04 +0300, Ville Voutilainen wrote:
> > > On Mon, 9 Jun 2025 at 14:17, Avi Kivity <avi_at_[hidden]> wrote:
> > > > The Standard should not make decisions that cannot be
> > > > implemented. But it also should not refrain from making
> > > > decisions that cannot be implemented optimally on every
> > > > platform, and instead leave it to the platform to make a
> > > > choice.
> > >
> > > Well, that leads to this question: would you like it to be
> > > portably
> > > reliable that destroying a
> > > vector<optional<vector<optional<string>>>>
> > > is fast, or would you like
> > > it to be theoretically but not practically fast?
> > >
> >
> >
> >
> > That's a good question.
> >
> >
> > > You can get the first part without such problems if you bite the
> > > bullet and make it a separate type.
> > >
> > > But that might not work, of course, because the committee might
> > > not want it.
> > >
> >
> >
> >
> > Well, I don't want it either. There's a lot of value in having
> > vocabulary types one uses everywhere.
> >
> > I'm not above reimplementing those vocabulary types (in fact, I
> > have my own string, born when libstdc++ std::string was still copy-
> > on-write) but it's not worthwhile to avoid a branch.
> >
> >
> > > You could try the second part, but that's then not portable
> > > because
> > > some vendors might not want it, and chances are that none of them
> > > want
> > > it,
> > > so it's portable in the sense that no practical implementation
> > > provides it.
> > >
> > > I'm not dismissing the idea, I love it; if I had a time machine,
> > > I'd
> > > travel back in time and incorporate such a "cheap to
> > > default-construct, so do that instead
> > > of constructing nothing" into optional's design. But it's quite a
> > > different exercise to try to adapt it in afterwards.
> >
> >
> > I'm rather asking for a dummy value protocol, and leave it to
> > implementations and user types to choose whether to incorporate it
> > into std::optional or their own type.
> >
> > Perhaps a different angle: just as we have
> > [[trivially_relocatable]] (move+destroy == memcpy), add
> > [[trivially_constructible]] and define it to memset(p, 0, sizeof).
> > This works for unique_ptr, the trivial types, std::string, many
> > others. User classes can use it to optimize unions and
> > implementations can choose whether to use it in std::optional or
> > not.
> >
> >