WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Friday, 25 July 2014 at 10:27:27 UTC, Daniel Gibson wrote:
> Am 25.07.2014 12:07, schrieb Jonathan M Davis:
>> And once you define opEquals, you have to define
>> toHash. So, what you're suggesting would force a lot more code 
>> to define
>> toHash, which will likely cause far more bugs than simply 
>> requiring that
>
> Is it actually hard to define toHash, or should it be?
> What is done by default? I guess some magic hash is built over 
> all members of a type (like all members are compared in 
> opEquals).
> So couldn't there be some templated function that creates the 
> hash for you in the same way as it's done now, but only for the 
> values you want to hash?

Sure. We could create something like that, and we probably 
should. It would help out in cases where the default wasn't 
appropriate (e.g. only some of the member variables were part of 
opEquals). But why force folks to define opEquals and toHash when 
the defaults would have worked fine for them just to fix the code 
of folks who didn't make the effort to test that opEquals and 
lhs.opCmp(rhs) == 0 were equivalent? That seems to me like we're 
punishing the folks who actually write good code and test it in 
order to help those who don't even test the basic functionality 
of their types.

- Jonathan M Davis