On 25 July 2014 14:50, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13179

Consider also:

http://www.reddit.com/r/programming/comments/2bl51j/programming_in_d_a_great_online_book_for_learning/cj75gm9

The current scheme breaks existing code - code that was formerly correct and working.

AAs don't make sense if the notion of == on members is invalid. AAs formerly required opCmp, and yes, opCmp could be constructed to give different results for opCmp==0 than ==, but I would expect such an object to not be used in an AA, again because it doesn't make sense.

Using the default generated opEquals for AAs may break code, such as the an AA of the structs in the parent post, but it seems unlikely that that code was correct anyway in an AA (as it would give erratic results).

Kenji's rebuttal https://issues.dlang.org/show_bug.cgi?id=13179#c2 is probably the best counter-argument, and I'd go with it if it didn't result in code breakage.

I don't really see how opCmp == 0 could be unreliable or unintended. It was deliberately written by the author, so definitely not unintended, and I can't imagine anybody would ever deliberately ignore the == 0 case when implementing an opCmp, or produce logic that works for less or greater, but fails for equal.
<= and >= are expressed by opCmp, which imply that testing for equality definitely works as the user intended.

In lieu of an opEquals, how can a deliberately implemented opCmp, which we know works in the == case (otherwise <= or >= wouldn't work either) ever be a worse choice than an implicitly generated opEquals?

Personally, just skimming through this thread, I find it baffling that this is controversial.