WAT: opCmp and opEquals woes

[Andrei Alexandrescu via Digitalmars-d]

On 7/26/14, 2:19 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
> On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via Digitalmars-d wrote:
>>> It's okay, I hate it too.
>>> But I equally can't abide == meaning something different than <, <=,
>>> etc.
>>> That's insane.
>>
>> Yes, it is unsound to use opCmp for types that aren't totally ordered:
>
> Yes, that's why it's possible to provide opEquals in addition to opCmp.
> But for the vast majority of cases, opEquals _is_ equivalent to opCmp ==
> 0, and element-wise equality is not. Defining opEquals to be the latter
> by default _even in the presence of opCmp_ is therefore wrong in almost
> all cases.

Case-insensitive ordering is a simple example. Field for field 
comparison is the right default whether or not opCmp is defined.

Andrei