WAT: opCmp and opEquals woes

[Manu via Digitalmars-d]

On 26 July 2014 19:48, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> 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.
>

...you're trolling me right?

Just to be clear, you're saying you think it's reasonable for <, <=, >=, >
to perform case insensitive comparison for ordering purposes, but for ==,
!= to be case sensitive for equality comparisons?
You're saying you think that's what the user *probably* wants, by default?
Is there precedent for something like this? I've never seen anything like
it.
It creates very awkward relationships between the suite of operators which
is likely to break down in many logical constructs.

I don't understand; your example is the perfect example of why opCmp==0
should be the default opEquals, but somehow it's an argument against? I
have no idea how to reason about this topic.
I come from a place where <,<=,==,!=,>=,> are a suite, and it is reasonable
to assume they all work the same. Is that not the default presumption of
modern programmers? Is it really so unlikely that people would make the
mistake of assuming they are related?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140727/1a1478c2/attachment.html>