[Issue 13179] AA key type TagIndex now requires equality rather than comparison

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13179

--- Comment #21 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Jacob Carlborg from comment #20)
> If you define opCmp it means that the default generated isn't correct for
> you. If the default opCmp isn't correct, how often will the default opEquals
> be correct then. I mean, will there be uses where the default opEquals is
> correct but not the default opCmp.
> 
> Generating opEquals to call opCmp == 0 if opCmp is defined will be a
> breaking change but it will only change the behavior if previously
> lhs.opCmp(rhs) == 0 was _not_ the same as lhs == rhs, which you defined as a
> bug. So to me this looks like it will fix bugs.

The compiler does not define opCmp for you. If you don't define it, none of the
other comparison operators work. You define opCmp, because you want your struct
to work with <, <=, >=, and >. == has nothing to do with it. And if you define
opCmp so that lhs.opCmp(rhs) == 0 is not equivalent to opEquals, then one of
the two needs to be fixed so that they _are_ equivalent; otherwise it's a bug.
If that means having to define opEquals instead of the built-in one, then you
have to define it, but in many cases, the built-in one is correct, and you
simply added opCmp in order to get the other comparison operators.

So, if we make opEquals be generated as lhs.opCmp(rhs) == 0 when opCmp is
defined, then that will incur a performance hit, and it will only be more
correct if the struct was broken in the first place. So, we'd be penalizing
code that was written correctly just to fix bugs in code that didn't define
opEquals like when should have. And that still wouldn't fix code where opEquals
_was_ defined but it was defined incorrectly.

So, as far as I can see, changing the default opEquals implementation to use
opCmp just penalizes the folks who made sure that opCmp was correctly
implemented. I don't see any reason to try and fix broken code by changing the
language, especially when that penalizes correct code.

And FWIW, Walter agrees with me:
http://forum.dlang.org/post/lqsnmu$2f3q$1@digitalmars.com

--