WAT: opCmp and opEquals woes

[Ary Borenszweig via Digitalmars-d]

On 7/25/14, 3:31 AM, Jonathan M Davis wrote:
> On Friday, 25 July 2014 at 04:50:38 UTC, Walter Bright 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).
>
> Exactly. The only reason that switching from using lhs.opCmp(rhs) == 0
> to opEquals would break code is if a type does not define them such that
> they're equivalent, which would mean that opEquals and/or opCmp was
> defined in a buggy manner. So, the only way that the change would break
> code is if it was broken in the first place. All it risks is making it
> so that the bug exhibits itself in an additional case.

Not at all.

If you have a type that has partial ordering (only cares about opCmp, 
not about opEquals), but still keeps the default opEquals, then this 
would silently break someone's code by changing their opEquals semantic.

THIS is the breaking change.