This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2023-01-15


52. Non-static members, member selection and access checking

Section: 7.6.1.5  [expr.ref]     Status: TC1     Submitter: Steve Adamczyk     Date: 13 Oct 1998

7.6.1.5 [expr.ref] paragraph 4 should make it clear that when a nonstatic member is referenced in a member selection operation, the type of the left operand is implicitly cast to the naming class of the member. This allows for the detection of access and ambiguity errors on that implicit cast.

Proposed Resolution (10/00):

  1. In 11.8.3 [class.access.base] paragraph 4, remove the following from the second note:

    If the member m is accessible when named in the naming class according to the rules below, the access to m is nonetheless ill-formed if the type of p cannot be implicitly converted to type T (for example, if T is an inaccessible base class of p's class).
  2. Add the following as a new paragraph 5 of 11.8.3 [class.access.base]:

    If a class member access operator, including an implicit "this->," is used to access a nonstatic data member or nonstatic member function, the reference is ill-formed if the left operand (considered as a pointer in the "." operator case) cannot be implicitly converted to a pointer to the naming class of the right operand. [Note: this requirement is in addition to the requirement that the member be accessible as named.]
  3. In 11.8.3 [class.access.base] paragraph 4, fix a typographical error by adding the missing right parenthesis following the text

    (including cases where an implicit "this->" is added
  4. Add following the first sentence of 7.6.1.3 [expr.call] paragraph 4:

    If the function is a nonstatic member function, the "this" parameter of the function (_N4868_.11.4.3.2 [class.this]) shall be initialized with a pointer to the object of the call, converted as if by an explicit type conversion (7.6.3 [expr.cast]). [Note: there is no access checking on this conversion; the access checking is done as part of the (possibly implicit) class member access operator. See 11.8.3 [class.access.base].]