WAT: opCmp and opEquals woes

[Andrei Alexandrescu via Digitalmars-d]

On 7/26/14, 7:58 PM, Manu via Digitalmars-d wrote:
> On 26 July 2014 19:48, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>
>     On 7/26/14, 2:19 AM, "Marc Schütz" <schuetzm at gmx.net
>     <mailto: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?

No.

> 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?

Odder examples have been shown here in support of various other points. 
I certainly think it's possible, and it's not a bug by definition.

> You're saying you think that's what the user *probably* wants, by
> default?

Yes.

> Is there precedent for something like this?

In all likelihood.

>  I've never seen
> anything like it.

Time to expand one's social circle :o).

> It creates very awkward relationships between the suite of operators
> which is likely to break down in many logical constructs.

Doesn't seem that drastic to me.

> 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..

You yourself seemed to reach for an operator ===. In fact those 
comparisons you think should exist already exist: what you claim "==" 
should be is really !(a < b) && !(b < a) or !opCmp(a, b); and what you 
think "===" should be is really "==".

> I come from a place where <,<=,==,!=,>=,> are a suite, and it is
> reasonable to assume they all work the same.

I think that place is not a good place. That's not a reasonable assumption.

> Is that not the default
> presumption of modern programmers?

No.

> Is it really so unlikely that people
> would make the mistake of assuming they are related?

Yes.


Andrei