CWG Issue 1121 (original) (raw)

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

2025-11-05

1121. Unnecessary ambiguity error in formation of pointer to member

Section: 7.6.2.2 [expr.unary.op]Status: C++11Submitter: USDate: 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 ofissue 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 7.6.2.2 [expr.unary.op] paragraph 3 as follows:

...If the operand is a qualified-id naming a non-static memberm of some class C with type T, the result has type “pointer to member of class C of typeT 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...

1. Change 6.5.2 [class.member.lookup] paragraph 13 as follows:

[_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], 7.6.1.5 [expr.ref],7.6.2.2 [expr.unary.op], 11.8.3 [class.access.base]). —_end note_]...