Proposed resolution:

This wording is relative to N3691.

Change Table 19 in [utility.arg.requirements] as indicated:

[ 2014-02-15 Issaquah: Move to Ready ]

AM: core says still LWG issue, wording has been non-controversial, move to ready?

NJ: what about durations? think they are ok

Ville: pair and a few other have value initialize

AM: look at core 1578

AM: value initialize would require (), remove braces from third row?

STL: no

PH: core has new issue on aggregates and non-aggregates.

AM: right, they said does not affect this issue

NJ: why ok with pair and tuple?

STL: will use (), tuple of aggregates with deleted constructor is ill-formed

Ville: aggregate with reference can't have ()

STL: {} would be an issue too

Ville: aggregate with reference will have () deleted implicitly

Move to Ready.

[ 2013-04 Bristol: Back to Library ]

The Core Working group opened, discussed, and resolved CWG 1578 as NAD for this library-related problem: Empty aggregate initialization and value-initialization are different core language concepts, and this difference can be observed (e.g. for a type with a deleted default-constructor).

[ 2012-10 Portland: Move to Core ]

We are not qualified to pick apart the Core rules quickly at this point, but the consensus is that if the core language has changed in this manner, then the fix should similarly be applied in Core - this is not something that we want users of the language to have to say every time they want to Value initialize (or aggregate initialize) an object.

More to Open until we get a clear response from Core, Alisdair to file an issue with Mike.

The lack of the definition of the DefaultConstructible requirements in C++03 was fixed by LWG 724 at a time where the core rules of list-initialization were slightly different than today, at that time value-initialization (shortly) was the primary rule for class types, i.e. just before applying CWG 1301, CWG 1324, and CWG 1368.

The order in [dcl.init.list] p3 was changed to respect aggregate initialization, but that had the side-effect that formally aggregate types cannot satisfy the DefaultConstructible requirements anymore, because we require that

T u{};

value-initializes the object u.

Of-course exclusion of aggregates was not intended, therefore I suggest to extend the requirements in Table 19 ([utility.arg.requirements]) for empty aggregate-initialization as well.