https://issues.dlang.org/show_bug.cgi?id=13179
--- Comment #15 from Jonathan M Davis <jmdavisp...@gmx.com> --- (In reply to hsteoh from comment #14) > But there's no reason to require toHash to be defined if the user never > tries to use it as an AA key, even if they define opEquals. Agreed. I don't think that I said otherwise. What I was trying to point out that is if you define opEquals, then if you use the type with an AA, then you're going to need to define toHash as well. So, forcing the user to define opEquals simply because they defined opCmp potentially forces them to define toHash. And if the compiler-generate opEquals and toHash would have been consistent with opCmp, then having to define them just increases the risk that you're going to screw up defining them (particular toHash). What it would mean would be that any type that you wanted to use as an AA key that defined opCmp (as was previously required) would then have to define opEquals and toHash as well even if it shouldn't be necessary. So, I favor just having the compiler continue to generate opEquals and toHash even if opCmp is defined. If opCmp is not consistent with opEquals, then that's a bug, and the programmer will need to either fix opCmp or define opEquals (and toHash if using AAs) so that it's consistent with opCmp. Requiring that the user define opEquals won't necessarily make it less likely to be inconsistent with opCmp, because then instead of relying on the built-in opEquals in the cases where it would have been fine, you'd then have to define it and would potentially screw it up. And if they both need to be defined in order to be consistent, then it's always up to the programmer to get it right anyway. But I think that making it so that defining opCmp results in opEquals being generated as a.opCmp(b) == 0 is pernicious, because it's a hidden performance hit. --
