opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Friday, 25 July 2014 at 07:34:29 UTC, Daniel Murphy wrote:
> "Jonathan M Davis"  wrote in message 
> news:zcutsbuilcttvbuahmlc at forum.dlang.org...
>
>> 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