Comment #0 by eatingstaples — 2011-02-18T04:09:28Z
Created attachment 916
Code demonstrating the issue.
The language specification states (with respect to opEquals in structs) "...the
expressions a.opEquals(b) and b.opEquals(a) are tried. If both resolve to the
same opEquals function, then the expression is rewritten to be a.opEquals(b).
If one is a better match then the other, or one compiles and the other does
not, the one is selected.
Otherwise, an error results."
Structs, however, don't properly follow the "if one compiles and the other does
not" rule, at least not for the form a.opEquals(rvalue). Example attached.
Comment #1 by kennytm — 2011-05-11T10:40:22Z
*** Issue 5979 has been marked as a duplicate of this issue. ***
Comment #2 by lovelydear — 2012-04-22T16:23:34Z
Code in the attachment:
struct A
{
int x;
A foo()
{
return A(x);
}
const bool opEquals(ref const A other)
{
return (x == other.x);
}
}
void main()
{
auto a = A(5);
assert(a.foo == a); // OK
assert(a == a.foo); // Error
}
Comment #3 by razvan.nitu1305 — 2022-08-15T14:18:38Z
This bug report highlights a misunderstanding of the spec [1]. It is clearly stated: "Otherwise the expressions a.opEquals(b) and b.opEquals(a) are tried. If both resolve to the same opEquals function, then the expression is rewritten to be a.opEquals(b).". So, in the provided test case a.opEquals(b) and b.opEquals(a) resolve to the same function therefore `a.opEquals(b)` is selected. Only if opEquals did not resolve to the same function the compiler would have tried to semantically analyze the 2 constructions.
So this bug report is invalid.
[1] https://dlang.org/spec/operatoroverloading.html#equals