WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

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 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.

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.

> Frankly, I find this rather incongruous. First you say that 
> requiring
> programmers to define toHash themselves is too high an 
> expectation, then
> you say that you have no sympathy on these same programmers 
> 'cos they
> can't get their opEquals code right. If it's too much to expect 
> them to
> write toHash properly, why would we expect them to write 
> opEquals
> correctly either? But if they *are* expected to get opEquals 
> right, then
> why is it a problem for them to also get toHash right? I'm 
> honestly
> baffled at what your point is.

opEquals is trivial. toHash is much harder to get right, 
especially if you want a hash function that's even halfway decent.

- Jonathan M Davis