A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://cplusplus.github.io/CWG/issues/1608.html below:

CWG Issue 1608

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

2025-08-11

1608. Operator lookup in trailing return typeSection: 12.2.2.3  [over.match.oper]     Status: C++14     Submitter: Johannes Schaub     Date: 2013-01-23

[Moved to DR at the September, 2013 meeting.]

There is an unfortunate disparity between the treatment of an example 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 is 12.2.2.3 [over.match.oper] paragraph 3:

For a unary operator @ with an operand of a type whose cv-unqualified version is T1, and for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2, three sets of candidate functions, designated member candidates, non-member candidates and built-in candidates, are constructed as follows:

It would be desirable to update the latter specification to allow lookup of preceding declarations in a class currently being defined, analogously with 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:


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4