Is aggregate member copy-initialization associated with the corresponding initializer-clause?

[Edward Catmur]

From http://stackoverflow.com/q/21294831/567292:

struct S { int i; int j; };
int f() { S s{5, s.i}; return s.j; }

Is this defined behavior?

[dcl.init.aggr]/2 has:

When an aggregate is initialized by an initializer list, as specified in 8.5.4, the elements of the initializer list
are taken as initializers for the members of the aggregate, in increasing subscript or member order. Each
member is copy-initialized from the corresponding initializer-clause.

[dcl.init.list]/4 has:

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack
expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and
side effect associated with a given initializer-clause is sequenced before every value computation and side
effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.

The copy-initialization of an aggregate member is certainly a side effect, but is it "associated with" the corresponding initializer-clause or is that only intended to cover side-effects like in S s{++i, ++i}?

The alternative would be that the copy-initialization of aggregate members is associated with the full-expression; this could e.g. be more efficient where it is possible to initialize multiple aggregate members en bloc.

[David Krauss]

On 2015–02–24, at 5:10 AM, Edward Catmur <e...@catmur.co.uk> wrote:

From http://stackoverflow.com/q/21294831/567292:

struct S { int i; int j; };
int f() { S s{5, s.i}; return s.j; }

Is this defined behavior?

My impression is that it remains unspecified that the initialization of the variable is part of the evaluation of the initializer full-expression. However, it would take a pathological implementation to fail to do so.