[PATCH 1/2] libstdc++: Add missing initializers for __maybe_present_t members [PR119962]

[Patrick Palka]

On Tue, 15 Jul 2025, Jonathan Wakely wrote:

> On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski <tkaminsk@redhat.com> wrote:
> >
> >
> >
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka <ppalka@redhat.com> wrote:
> >>
> >> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> >> 15?  Not sure if this corner case is worth backporting any further.
> >>
> >> Can we just use direct-list-initialization via {} instead of '= T()'
> >> here?  I wasn't sure so I went with the latter to more closely mirror
> >> the standard.
> >
> > default_initializable (https://eel.is/c++draft/concept.default.init#concept:default_initializable)
> > implies that T{} is well-formed, however there is no semantic
> > requirements that T() and T{} are the same.
> >
> > The only case when {} could break, and "= T()" would work, is an aggregate that has
> > members with explicit default constructor, but it would be ill-formed. There is also difference
> > between lifetime of reference members with default initializers (binding to temporary), but
> > it does not matter for members of the class, as they go away with constructors.
> >
> > There is also, pre-C++20 case, where classes with deleted default constructor, where initializable
> > via {} but not = T(). But again, default_initializable requires both.
> >
> > So, as far I can tell if we require T being default_initializable, we can use {} for initialization, but
> > given that aggregate initialization/defintion changes every standard (you can now mix base and
> > designated init in C++26), I would just use = T().

Interesting, thanks!

> 
> Yes, that's my thinking too.
> 
> OK for trunk and gcc-15.