WAT: opCmp and opEquals woes

[via Digitalmars-d]

On Friday, 25 July 2014 at 18:45:30 UTC, Jonathan M Davis wrote:
> On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via 
> Digitalmars-d wrote:
>> On Fri, Jul 25, 2014 at 09:46:55AM +0000, Jonathan M Davis via 
>> Digitalmars-d wrote:
>>> Even worse, if you define opEquals, you're then forced to 
>>> define
>>> toHash, which is much harder to get right.
>>
>> If you're redefining opCmp and opEquals, I seriously question 
>> whether
>> the default toHash actually produces the correct result. If it 
>> did, it
>> begs the question, what's the point of redefining opCmp?
>
> Except that with the current git master, you're forced to 
> define opEquals just because you define opCmp, which would then 
> force you to define opCmp. And with your suggested  fix of
(assuming you mean "toHash")
> making opEquals equivalent to lhs.opCmp(rhs) == 0, then _every_ 
> type with opCmp will have to define toHash, because the default 
> toHash is for the default opEquals, not for a user-defined 
> opCmp.

No, only those types that define opCmp _and_ are going to be used 
as AA keys, and that's sensible. All others don't need toHash.

>
> And remember that a lot of types have opCmp just to work with 
> AAs, so all of a sudden, _every_ user-defined type which is 
> used as an AA key will have to define toHash.

No, if a type had only defined opCmp because of the previous AA 
(mis)implementation, it needs to be changed with any of the 
suggested solutions: If opEquals is not going to be 
auto-generated, the user needs to add it, if it is, the user has 
the choice between adding toHash, or (more likely, as opCmp 
usually isn't necessary) changing opCmp into opEquals.