WAT: opCmp and opEquals woes

[via Digitalmars-d]

On Saturday, 26 July 2014 at 09:48:55 UTC, Andrei Alexandrescu 
wrote:
> 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.

If you're starting with the premise that the user's intention was 
to keep the default semantics of opEquals, then yes. I just find 
this unlikely. To take your example, I for one would fully expect 
"hello WORLD" and "Hello World" to be considered equal in all 
circumstances, not just when sorting.

If you want it to be restricted to sorting, it should probably 
not be a property of the type, but a predicate should be used 
instead for sorting. If you still want it to be different, just 
define an opEquals, it's trivial using `tupleof`.

Indeed, both options make assumptions about the user's 
intentions, but IMO the assumption for opEquals not using opCmp 
is the more unlikely one. Maybe we can then at least require the 
user to specify explicitly what she wants, as H.S. Teoh (?) 
suggested? Maybe for now implement whatever has been the default 
before to minimize breakage, but deprecate it with an appropriate 
message, and remove it a few releases down the road?