Aggregate initialization of a struct, using its own data members

Question

_{This is the n-th question about this, but I couldn't find exact duplicate...}

Suppose the following code:

#include <iostream>

struct S {
    int x;
    int y;
};

class C {
public:
    S s;
    C() : s{123, s.x} {}
};

int main() {
     std::cout << C().s.y << '\n';
}

Is it OK to initialize s.y like this? (only JetBrains' ReSharper complains about it with the following: Object member this->s.x might not be initialized).

It would be great if someone confirms their answer with a quote from the standard.

Answer 1

From C++14

8.5.1 Aggregates [dcl.init.aggr]

1 An aggregate is an array or a class (Clause 9) with no user-provided constructors (12.1), no private or protected non-static data members (Clause 11), no base classes (Clause 10), and no virtual functions (10.3).

2 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.

This means that s.x is first initialized with 123, then s.y is initialized with s.x.

Without optimization, GCC 6.3 generates

C::C():
        push    rbp
        mov     rbp, rsp
        mov     QWORD PTR [rbp-8], rdi
        mov     rax, QWORD PTR [rbp-8] # read address of s
        mov     DWORD PTR [rax], 123   # write 123 to s.x (offset 0 from s)
        mov     rax, QWORD PTR [rbp-8] # read address of s again
        mov     edx, DWORD PTR [rax]   # read contents of s.x to edx
        mov     rax, QWORD PTR [rbp-8] # read address of s
        mov     DWORD PTR [rax+4], edx # write s.y (offset 4 from s)
        nop
        pop     rbp
        ret

Which agrees with what the standards says.

Answer 2

While it would seem that there is no rule that explicitly states that this trick is ill-formed, it is not enough for it to have a well-defined behavior.

I think it has some issues with order of evaluation:

this rule defines the order of evaluation for the expressions in the braced list; Of course, there is an order for member initialization too.

It is safe to say that every struct member is initialized after the evaluation of the corresponding expression in the bracket list (obviously s.x in the braced list is evaluated before initializing s.y).

However there seem to be no rule that would state that s.x in your case has to be initialized before evaluating the second element of braced list, e.g. the program could evaluate all the expressions in the bracket list before even starting initializing the struct fields.

Of course, the absence of a rule is not easy to prove, but if it's not there, it looks like UB.

UPD: the rule from @PaulFloyd's answer does indeed closely resemble what was missing in my answer, perhaps it's not a UB after all.