On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski <tkami...@redhat.com> wrote:
>
>
>
> On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka <ppa...@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().
Yes, that's my thinking too.
OK for trunk and gcc-15.
