On Sat, Feb 1, 2020 at 10:04 AM Andrey Davydov <andrey.davydov_at_[hidden]>
wrote:

> On Fri, Jan 31, 2020 at 6:07 PM Anton Bikineev via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> The Standard says:
>>
>> To *value-initialize*
>>> <http://eel.is/c++draft/dcl.init#def:value-initialization> an object of
>>> type T means:
>>>
>>> - - if T is a (possibly cv-qualified) class type with either no
>>> default constructor or a default constructor that is user-provided or
>>> deleted, then the object is default-initialized;
>>>
>>>
>>> - - if T is a (possibly cv-qualified) class type without a
>>> user-provided or deleted default constructor, **then the object is
>>> zero-initialized** and the semantic constraints for
>>> default-initialization are checked, and if T has a non-trivial
>>> default constructor, the object is default-initialized;
>>>
>>>
>>> - - ...
>>>
>>>
>> I'm wondering, why in C++11 an object needs to be zero-initialized (this
>> was not the case before C++11)? I can't find a proposal/DR that changes
>> that, but I suspect that this is to align with value-initialization of
>> scalar types (which implies zero-initializaiton).
>>
>
> I'm sure symmetry with value-initialization of scalar types is the reason.
> It would be very strange if for the `pair<int, array<int, 1>> p;` p.first
> == 0, but p.second[0] has indeterminate value.
>
>
>> The problem is that this leads to suboptimal code generation:
>> https://godbolt.org/z/pwYjLP (this is a minimized example from optional
>> implementation in abseil).
>>
>
> Is it possible just to remove mem-initializer for `dummy` (
> https://godbolt.org/z/22zBTu)? Or, even better, remove definition of
> `optional()` to make it trivially-default-constructible?
>

Sorry, `optional()` couldn't be trivially-default-constructible (due to
initialization of `is_populated`), but I still don't see a reason to
value-initialize `dummy`.

-- 
Andrey Davydov