[class.cdtor] p2 needs changes/notes to clarify intent and limitations

[eisenwave]

[class.cdtor] p2 needs a note to clarify its limitations.

Bugs which lead back to this paragraph

GCC contributers have falsely interpreted this paragraph to mean that this can be marked __restrict. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899. A more detailed explanation for why this reading is incorrect can be found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912.

Proposed Solution (1/2)

1. I think the wording should be made more conventional, by using the term "value computation" instead of saying "the value ... thus obtained".
2. Only scalar type objects can be accessed [defns.access] Note 1, so any object which has subobjects cannot be accessed.

 During the construction of an object, if the value of
-the object or
 any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly,
 from the constructor's this pointer,
-the value of the object or subobject thus obtained is unspecified.
+the value computation of this subobject yields an unspecified value.

Proposed Solution (2/2)

Furthermore, it may be beneficial to add a note which clarifies that a side effect on the subobjects through such a glvalue will have the expected effect. The attached example could also include a case such as:

struct S {
    int x;
    S(int &r) {
        r = 0;  // if r refers to S::x, then this is equivalent to x = 0
    }
};

S s(s.x);

[frederick-vs-ja]

Only scalar type objects can be accessed

I think it's almost clarified that non-scalar objects can be accessed, although they must be accessed via scalar glvalues, see #4777.

[eisenwave]

Related: https://cplusplus.github.io/CWG/issues/2271.html. This issue removed the "const object" restriction for the paragraph, however, in its current state, it still isn't strong enough to imply __restrict.

[eisenwave]

Only scalar type objects can be accessed

I think it's almost clarified that non-scalar objects can be accessed, although they must be accessed via scalar glvalues, see #4777.

I see, in that case, part 1 could be limited to:

 During the construction of an object, if the value of the object or
 any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly,
 from the constructor's this pointer,
-the value of the object or subobject thus obtained is unspecified.
+the value computation of the object or subobject yields an unspecified value.