On Friday, 25 July 2014 at 08:21:26 UTC, Jacob Carlborg wrote:
By defining opEquals to be opCmp == 0 we're:
1. We're not breaking code where it wasn't broken previously
2. We're fixing broken code. That is when opEqual and opCmp ==
0 gave different results
Code that worked perfectly fine before is now slower, because
it's using opCmp for opEquals when it wasn't before. Even worse,
if you define opEquals, you're then forced to define toHash,
which is much harder to get right. So, in order to avoid a
performance hit on opEquals from defining opCmp, you now have to
define toHash, which significantly increases the chances of bugs.
And regardless of the increased risk of bugs, it's extra code
that you shouldn't need to write anyway, because the normal,
default opEquals and toHash worked just fine.
I honestly have no sympathy for anyone who defined opCmp to be
different from the default opEquals but didn't define opEquals.
Getting that right is simple, and it's trivial to test for you're
unit testing like you should be. I don't want to pay in my code
just to make the compiler friendlier to someone who didn't even
bother to do something so simple. And any code in that situation
has always been broken anyway. I'm _definitely_ not interested in
reducing the performance of existing code in order to fix bugs in
the code of folks who couldn't get opEquals or opCmp right.
I'd much rather be able to take advantage of the fast, default
opEquals and correct toHash than be forced to define them just
because I defined opCmp and didn't want a performance hit on
opEquals.
- Jonathan M Davis
