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
[Moved to DR at the September, 2013 meeting.]
There is an unfortunate disparity between the treatment of anexample like
struct S { int operator[](int); auto f() -> decltype(this->operator[](0)); };(which is permitted, cf _N4567_.5.1.1 [expr.prim.general] paragraph 3), and
struct S { int operator[](int); auto f() -> decltype((*this)[0]); };which is not. The reason for rejecting the latter is12.2.2.3 [over.match.oper] paragraph 3:
For a unary operator@ with an operand of a type whosecv-unqualified version isT1, and for a binary operator@with a left operand of a type whose cv-unqualified version isT1and a right operand of a type whose cv-unqualified version isT2,three sets of candidate functions, designated member candidates, non-membercandidates and built-in candidates, are constructed as follows:
IfT1 is a complete class type, the set of membercandidates is the result of the qualified lookup ofT1::operator@(12.2.2.2.2 [over.call.func]); otherwise, the set of member candidatesis empty.
...
It would be desirable to update the latter specification to allow lookupof preceding declarations in a class currently being defined, analogouslywith the lookup performed in the function-notation case.
Proposed resolution (April, 2013):
Change 12.2.2.3 [over.match.oper] bullet 3.1 as follows:
IfT1 is a complete class typeor a classcurrently being defined, the set of member candidatesis the result of the qualified lookupofT1::operator@ (12.2.2.2.2 [over.call.func]);otherwise, the set of member candidates is empty.