WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Friday, 25 July 2014 at 05:52:57 UTC, Manu via Digitalmars-d 
wrote:
> On 25 July 2014 14:50, Walter Bright via Digitalmars-d <
> digitalmars-d at 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.

So, in the case where opCmp was defined but not opEquals, instead 
of using the normal, built-in opEquals (which should already be 
equivalent to lhs.opCmp(rhs) == 0), we're going to make the 
compiler generate opEquals as lhs.opCmp(rhs) == 0? That's a 
silent performance hit for no good reason IMHO. It doesn't even 
improve correctness except in the cases where the programmer 
should have been defining opEquals in the first place, because 
lhs.opCmp(rhs) == 0 wasn't equivalent to the compiler-generate 
opEquals. So, we'd be making good code worse just to try and fix 
an existing bug in bad code in order to do what? Not break the 
already broken code?

I can understand wanting to avoid breaking code when changing 
from using opCmp to using opEquals with AAs, but it's only an 
issue if the code was already broken by defining opCmp in a way 
that didn't match opEquals, so if I find it odd that any part of 
this is controversial, it's the fact that anyone thinks that we 
should try and avoid breaking code where opEquals and opCmp 
weren't equivalent.

- Jonathan M Davis