Repository navigation
CWG2804 Lookup for determining rewrite targets #1688
Description
Activity
EWG discussed CWG2804 during the Tuesday Morning session in Kona. The following poll was taken.
CWG2804 "Lookup for determining rewrite targets", the intent is to check for the existence of a declaration that differs only in the operator name (ie,
bxshould work,byshould be ill-formed).SF F N A SA 4 11 3 0 0 Result: Consensus
@jensmaurer does this also resolve #1645 ?
@jfbastien : Yes, but this for sure makes the example in #1645 ill-formed. But we intentionally made this example well-formed very recently. So, EWG seems to have reversed direction as far as the example in #1645 is concerned.
The EWG decision partially reverts P2468R2 (The Equality Operator You Are Looking For), applied in July 2022. In particular, the line
bool c1 = B() == C();from the example added thereby is no longer well-formed.Back to EWG for confirmation of the intent.
Just so I understand, is the idea that the lookup for the corresponding
!=should be constrained to the same lexical scope?Note: the programming model suggested in P2468R2 was that if the programmer writes a corresponding
operator!=then the rewrite behavior foroperator==is dropped. From the perspective of the programming model,bxshould compile as shouldby(since the hidden friend function would indeed correspond to theoperator==as it is in the same scope as `operator!=).As for the standard reference:
struct B { bool operator==(const B&); // #2 }; struct C : B { C(); C(B); bool operator!=(const B&); // #3 }; bool c1 = B() == C(); // OK, calls #2; reversed #2 is not a candidate because search for operator!= in C finds #3
If we consider the programming model again, the sample should still compile as the scope S is
Bsince the two declarations would still correspond. I believe the wording can change however it needs to but the original programming model should be retained.My understanding of the programming model was that we use the fact that we find
==and!=declared together (lexically) as indication of user intent that they are a pair.So no rewrites here:
struct S { bool operator==(const S&) /* not const */; bool operator!=(const S&) /* not const */; };
or here
template <typename T> struct Base { bool operator==(const T&) const; bool operator!=(const T&) const; }; struct Derived : Base<Derived> { };
or here
struct X { operator int(); friend bool operator==(X, int); friend bool operator!=(X, int); }
since these are all declared together.
But in the standard reference example (that Cameron just cited) and in the
Yexample in the issue:struct Y { operator int(); friend bool operator==(Y, int); }; bool operator!=(Y, int);
The
==and!=aren't actually declared together. They're declared in a way such that there is a scope that they end up with that finds both - but that's not really the same thing. I can understand people writing those first examples - they wrote==and!=together, in some way, that happens to not be C++20-compatible, but they worked in C++17.But I don't super understand the other examples (the
B/Cfrom the standard reference and theYone from the issue). Have those shown up in real code, or did we construct theB/Cexample after we came up with the rule?My understanding of the
B/Cexample from the standard in particular was that this was representative of code found by Microsoft in the wild (possibly in their own corporate codebase), and that the wording was thus specifically crafted to avoid breakage there.Beyond that, I'd like to remind all interested parties that this paper tracker is for administrative purposes only. Any technical discussion should happen elsewhere, e.g. on the reflectors.
Reacted by Cameron DaCamara and A. Jiang- Reacted by Po-Yao (Kevin) Chang
If we are still looking for a paper author, I would like to express interest and signup for authoring this.
@usx95 has volunteered to write the paper, and I'm interacting with him offline to help get him started. So, author identified!
Reacted by Po-Yao (Kevin) Chang and A. JiangEWG St. Louis: @usx95 volunteered to write a paper
Metadata
Metadata
Assignees
Type
Projects
- Status
Some cases for synthesized equality operator candidates yield possibly surprising outcomes, owing to the details of the "rewrite target" rules.
CWG seeks the advice of EWG to possible improve or change these rules.
See CWG2804 for details.