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.
