https://issues.dlang.org/show_bug.cgi?id=13179
--- Comment #11 from Jonathan M Davis <jmdavisp...@gmx.com> --- (In reply to bearophile_hugs from comment #10) > (In reply to Jonathan M Davis from comment #9) > > I would not expect `a == b` to _ever_ be converted to `a.opCmp(b) == 0`. > > That's what opEquals is for. > > Why? When opCmp returns zero it means ==. What's wrong about using that > possible return value to test for equality? It's an unnecessary efficiency hit. The language has opEquals for a reason, and it's defined by the language to be ==, whereas opCmp is for <, <=, >=, and >. And code really shouldn't be calling opEquals or opCmp directly except under very rare circumstances. They're for generating overloaded operators, not for calling as normal functions. I can see an argument for just continuing to have the compiler define == when opCmp is defined in order to avoid having to declare opEquals as well when the default would be fine, and I can see an argument that opEquals should be explicitly defined in that case in order to reduce the odds of there being a bug when someone defined opCmp in a way that was inconsistent with the built in opEquals. But opEquals is what's supposed to be defining equality. That's what it's _for_. That's not opCmp's job. --