WAT: opCmp and opEquals woes

[Manu via Digitalmars-d]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140725/92df295d/attachment.html>