cplusplus / papers

ISO/IEC JTC1 SC22 WG21 paper scheduling and management
653 stars 18 forks source link

CWG2804 Lookup for determining rewrite targets #1688

Open jensmaurer opened 1 year ago

jensmaurer commented 1 year ago

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.

erichkeane commented 1 year ago

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

jfbastien commented 1 year ago

@jensmaurer does this also resolve https://github.com/cplusplus/papers/issues/1645 ?

jensmaurer commented 1 year ago

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

jensmaurer commented 1 year ago

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.

erichkeane commented 1 year ago

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.

brevzin commented 1 year ago

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

frederick-vs-ja commented 12 months ago

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

I believe @cdacamar is him.

cdacamar commented 12 months ago

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.

brevzin commented 12 months ago

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?

jensmaurer commented 12 months ago

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.

jensmaurer commented 12 months ago

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.

erichkeane commented 7 months ago

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.

usx95 commented 7 months ago

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

erichkeane commented 7 months ago

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

hanickadot commented 4 months ago

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