On Friday, 25 July 2014 at 07:34:29 UTC, Daniel Murphy wrote:
"Jonathan M Davis" wrote in message
news:[email protected]...
If that's the case, then the default opEquals isn't correct,
and the programmer should have already defined opEquals. If
they didn't, then their code is broken, and I see no reason to
penalize the folks who wrote correct code just to fix someone
else's broken code by then defining opEquals in terms of opCmp.
Just because not all fields _need_ to be compared doesn't mean
the default opEquals was incorrect. The ignored fields could
be cached values calculated from the other fields.
True. I didn't think of that. But even if that's the case, if
they don't define opEquals, then they've always been getting an
opEquals which compares all of them. The only place that they
would have gotten better performance would have be when the type
was used as the key in an AA, since that will now use opEquals
instead of opCmp. But if they want to get that efficiency gain,
then they can just define opEquals themselves - and if they
really cared about that gain, they would have already defined
opEquals themselves anyway, because the cases other than AAs
would have been using the default opEquals.
So, while you have a good point that opCmp _can_ be more
efficient than opEquals, it usually isn't, and the places where
that would make a difference should already be defining opEquals
anyway, meaning that changing the default opEquals to use opCmp
wouldn't gain them anything unless they didn't care about that
efficiency gain.
- Jonathan M Davis
