CWG2804 Lookup for determining rewrite targets

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.

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, bx should work, by should be ill-formed).

SF	F	N	A	SA
4	11	3	0	0

Result: Consensus

@jensmaurer

@jensmaurer does this also resolve #1645 ?

@jfbastien

@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.

@brevzin

EWG discussed this on Thursday PM in Kona, and request that the authors of P2468 (#1127 @brevzin et-al) review the original CWG2804 as well as the break that was caused by the fix to it, and come back with a more all-encompassing solution/set of questions as an omnibus as a revision to P2468.

@zygoloid

Tagging @zygoloid and... is Cameron not on github? What's his handle?

@zygoloid

Tagging @zygoloid and... is Cameron not on github? What's his handle?

I believe @cdacamar is him.

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 for operator== is dropped. From the perspective of the programming model, bx should compile as should by (since the hidden friend function would indeed correspond to the operator== 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 B since 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 Y example 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/C from the standard reference and the Y one from the issue). Have those shown up in real code, or did we construct the B/C example after we came up with the rule?

My understanding of the B/C example 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.

EWG discussed this during the Monday AM session in Tokyo. The following Poll was taken:

CWG2804 EWG agrees that this is an issue worth considering, but would like to see a paper to propose a change.

SF	F	N	A	SA
1	14	7	0	0

Result: Consensus

No paper author was identified.

If we are still looking for a paper author, I would like to express interest and signup for authoring this.

@usx95

@usx95 has volunteered to write the paper, and I'm interacting with him offline to help get him started. So, author identified!

@usx95

EWG St. Louis: @usx95 volunteered to write a paper

Navigation Menu

Repository navigation

CWG2804 Lookup for determining rewrite targets #1688

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CWG2804 Lookup for determining rewrite targets #1688

Description

Activity

erichkeane commented on Nov 7, 2023

jfbastien commented on Nov 7, 2023

jensmaurer commented on Nov 8, 2023

jensmaurer commented on Nov 8, 2023

erichkeane commented on Nov 10, 2023

brevzin commented on Nov 10, 2023

frederick-vs-ja commented on Nov 15, 2023

cdacamar commented on Nov 16, 2023

brevzin commented on Nov 16, 2023

jensmaurer commented on Nov 16, 2023

jensmaurer commented on Nov 16, 2023

erichkeane commented on Mar 18, 2024

usx95 commented on Mar 27, 2024

erichkeane commented on Apr 1, 2024

hanickadot commented on Jun 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions