Created attachment 916 [details] 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.
*** Issue 5979 has been marked as a duplicate of this issue. ***
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 }
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