This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110b. See for the official list.


1121. Unnecessary ambiguity error in formation of pointer to member

Section:  [expr.unary.op]     Status: C++11     Submitter: US     Date: 2010-08-02

[Voted into the WP at the November, 2010 meeting.]

N3092 comment US 33

The resolution of issue 983 restored an error, inadvertently removed by the resolution of issue 39, for the formation of a member of an ambiguous base class. For example:

    struct B { int i; };
    struct I1: B { };
    struct I2: B { };
    struct D: I1, I2 { };
    int B::* pm = &D::i;    // Originally and again ambiguous

This error is not necessary, because the result of taking the address of a member of an ambiguous base class is a pointer to a member of that class; an actual ambiguity would occur only if that pointer to a base class member is converted to a pointer to a member of the derived class. (See issue 203, which suggests changing the result of taking the address of a member to reflect the naming class of the member instead of the class of which it is directly a member; if that change were made, the ambiguity error would be needed.)

The resolution of issue 983 should be reverted.

Proposed resolution (August, 2010):

  1. Change [expr.unary.op] paragraph 3 as follows:

  2. ...If the operand is a qualified-id naming a non-static member m of some class C with type T, the result has type “pointer to member of class C of type T and is a prvalue designating C::m; the program is ill formed if C is an ambiguous base (10.2) of the class designated by the nested-name-specifier of the qualified-id. Otherwise...
  3. Change 6.5.2 [class.member.lookup] paragraph 13 as follows:

  4. [Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (7.3.13 [conv.mem], [expr.ref], [expr.unary.op], 11.8.3 [class.access.base]). —end note]...