WAT: opCmp and opEquals woes

[Daniel Gibson via Digitalmars-d]

Am 25.07.2014 20:45, schrieb Jonathan M Davis:
> 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.

That sentence doesn't make much sense, did you mean "opHash just because 
you define opEquals" or something similar?

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

As written before somewhere else, a toHash that is  as decent as the 
current default, but limited to the fields you actually want, should be 
really easy, if phobos exposed a function like
   hash_t createHash(T...)(T args)
that does to args what D currently does to all members to create the 
default hash.

(I kinda tend towards "whatever, maybe not defaulting opEquals to 
a.opCmp(b) == 0 is acceptable, people should stumble upon this when 
first reading the documentation on how to overload operators" now, though)

Cheers,
Daniel