[class.mem.general] Missing specification for types of member subobjects

[t3nsor]

Full name of submitter: Brian Bi

Issue description: The standard does not appear to specify the types of member subobjects. In particular, the manner in which the cv-qualifiers of the type of the enclosing class object combine with those of the member declaration is specified only for member access expressions ([expr.ref]), not for the type of the subobject itself.

Suggested resolution: Wording is relative to P3293R3 (adopted in Sofia).

Edit [expr.ref]/7.2:

Otherwise, if E2 designates a non-static data member and the type of E1 is “cq1 vq1 X”, and the type of E2 is “cq2 vq2 T”, the expression designates the corresponding member subobject of the object designated by E1 and its type is the type that a member subobject corresponding to the member designated by E2 would have in an object whose type is that of E1 ([class.mem.general]). If E1 is an lvalue, then E1.E2 is an lvalue; otherwise E1.E2 is an xvalue. If the entity designated by E2 is declared to be a mutable member, then the type of E1.E2 is “vq12 T”. If the entity designated by E2 is not declared to be a mutable member, then the type of E1.E2 is “cq12 vq12 T”.

Edit [class.mem.general]/6+:

Every object of class type has a unique member subobject corresponding to each of its direct non-static data members. For a non-static data member of non-reference type "cq2 vq2 T" that is a direct member of an object whose type is "cq1 vq1 C", let vq12 be volatile if either vq1 or vq2 is volatile, and empty otherwise, and let cq12 be const if either cq1 or cq2 is const, and empty otherwise. If the member is declared mutable, then the type of the corresponding subobject is "vq12 T"; otherwise, the type of the corresponding subobject is "cq12 vq12 T". If any non-static data member of a class C is of reference type, then let D be an invented class that is identical to C except that each non-static data member of D corresponding to a member of C of type "reference to T" instead has type "pointer to T". Every member subobject of a complete object of type C has the same type, size, alignment, and offset as that of the corresponding subobject of a complete object of type D. The size and alignment of C are the same as the size and alignment of D.

[frederick-vs-ja]

Considering CWG2514, would it be possible to specify that const and volatile are only added to the type of the member access expressions, but not the type of the member subobjects? I.e. given a non-const pair<const K, V> variable x, making x.first a const K lvalue denoting a (non-const) K subobject.

[t3nsor]

Considering CWG2514, would it be possible to specify that const and volatile are only added to the type of the member access expressions, but not the type of the member subobjects? I.e. given a non-const pair<const K, V> variable x, making x.first a const K lvalue denoting a (non-const) K subobject.

The fact that we allow transparent replacement doesn't mean that arbitrary modifications are possible. In particular, if a class has a private const member that it gives out const references to (via its public interface) it can be assumed that the member is always in a state that can be reached by calling one of the class's constructors: you can't transparently replace the subobject alone. Allowing the user to modify the subobject by casting away const changes what is possible and I think it's evolutionary.

Edit: Looking at [intro.object]/2 again, it seems that I'm only half right. The newly created object would not transparently replace the old one, but it would still become a member subobject of the enclosing object. Odd.

[t3nsor]

I've realized that we have the same issue with base class subobjects, so here's some suggested wording to cover that case too:

Edit [expr.ref]/7.6 (added by P3293R3):

Otherwise, if E2 designates a direct base class relationship (D, B) and the type of E1 is cv T, the expression designates the direct base class subobject of type B "cv B" of the object designated by E1. If E1 is an lvalue, then E1.E2 is an lvalue; otherwise, E1.E2 is an xvalue. The type of E1.E2 is “cv B”. [ Note 1: This can only occur in an expression of the form e1.[:e2:]. — end note ]

Edit [class.mi]/4:

A base class specifier that does not contain the keyword virtual specifies a non-virtual base class. A base class specifier that contains the keyword virtual specifies a virtual base class. For each distinct occurrence of a non-virtual base class A in the class lattice of the most derived class C, thea most derived object ([intro.object]) of type "cv C" shall contain a corresponding distinct base class subobject of that type "cv A". For each distinct base class B that is specified virtual, the most derived object shall contain a single base class subobject of that type "cv B".