This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Voted into WP at March, 2010 meeting.]
The resolution of issue 39 changed the diagnosis of ambiguity because of multiple subobjects from being a lookup error to being diagnosed where the result of the lookup is used. The formation of a pointer to member is one such context but was overlooked in the changes. 18.104.22.168 [expr.unary.op] paragraph 3 should have language similar to 22.214.171.124 [expr.ref] paragraph 5 and should be mentioned in the note in 6.5.2 [class.member.lookup] paragraph 13.
Proposed resolution (October, 2009):
Change 126.96.36.199 [expr.unary.op] paragraph 3 as follows:
...For a qualified-id, if the member is a static member of type “T”, the type of the result is plain “pointer to T.” If the member is a non-static member of class C of type T, the type of the result is “pointer to member of class C of type T
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], 188.8.131.52 [expr.ref], 11.8.3 [class.access.base]). —end note] [Example:...