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
