"Ola Fosheim Grøstad" " wrote in message news:qxtukjuohhzngcutmmpz@forum.dlang.org...

> On Wednesday, 23 July 2014 at 23:02:48 UTC, H. S. Teoh via Digitalmars-d wrote:
> >> fuzzy numbers it gets even worse. You can define it such that a<b and
> >> b>a both are true...
> >
> > (a<b && b>a) is true for ints.
>
> That was a typo, for fuzzy numbers you can define less than such that a<b and b>a both are true.
>
> Fuzzy(-1,0,1) vs Fuzzy(-2,0,2)

a<b and b>a can be true for ints. 

"Jonathan M Davis"  wrote in message news:kquxovegjzzsivftxsud@forum.dlang.org...

> The best option though would be to provide some way for the programmer to tell the compiler that they want to use the default one so that they still have to declare opEquals when they define opCmp (to make sure that the programmer didn't forget it), but they're still able to use the built-in one rather than writing it themselves. IIRC, C++11 has a way of doing that. Maybe we should add something similar.

bool opEquals(const ref other) const { return this.tupleof == other.tupleof; } 

On 24/07/14 02:41, Jonathan M Davis wrote:

> That would incur a silent performance hit.

So does default initialized values, virtual by default, classes allocated on the heap and other features of D. By default D chooses safety and correctness. If the programmer needs more performance some additional code might be required.

-- 
/Jacob Carlborg

On Thursday, 24 July 2014 at 06:18:34 UTC, Daniel Murphy wrote:
> "Ola Fosheim Grøstad" " wrote in message news:qxtukjuohhzngcutmmpz@forum.dlang.org...
>
>> On Wednesday, 23 July 2014 at 23:02:48 UTC, H. S. Teoh via Digitalmars-d wrote:
>> >> fuzzy numbers it gets even worse. You can define it such that a<b and
>> >> b>a both are true...
>> >
>> > (a<b && b>a) is true for ints.
>>
>> That was a typo, for fuzzy numbers you can define less than such that a<b and b>a both are true.
>>
>> Fuzzy(-1,0,1) vs Fuzzy(-2,0,2)
>
> a<b and b>a can be true for ints.

So I keep making the same typo :P...

For fuzzy numbers you can define less than such that a<b and b<a both are true... yes?

"Ola Fosheim Grøstad" " wrote in message news:duuhouucozvosboibhtc@forum.dlang.org...

> For fuzzy numbers you can define less than such that a<b and b<a both are true... yes?

You could, but if you do it with opCmp it looks like operator overloading abuse to me. 

Am 24.07.2014 01:52, schrieb Andrei Alexandrescu:
>
> I'm unconvinced. Most algorithms that need inequality don't need
> equality comparison; instead, they consider objects for which both !(a <
> b) && !(b < a) in the same "equivalence class" that doesn't assume they
> are actually equal.
>
> Bottom line, inferring opEquals from opCmp seems fishy.
>

You're thinking too algorithm-centric :-P

When I implement the "comparison operator" for my type, I expect it to be used for comparisons - and that includes equality.
If I had the feeling that I could implement == in a more efficient way, or that I actually want equality to have different semantics, I'd just implement opEquals as well.

IMHO, everything else would be just confusing to the "average" user, and if someone wants to be confused by counterintuitive rules (however much sense they may make in some way) he could as well just use C++ instead.

But if the general view really is that opEquals should *not* be opCmp == 0 by default, for performance reasons or whatever, then please enforce defining opEquals when opCmd is defined, so it's at least explicit that opCmd does not define equality.

Cheers,
Daniel

On Thursday, 24 July 2014 at 06:46:08 UTC, Daniel Murphy wrote:
> "Ola Fosheim Grøstad" " wrote in message news:duuhouucozvosboibhtc@forum.dlang.org...
>
>> For fuzzy numbers you can define less than such that a<b and b<a both are true... yes?
>
> You could, but if you do it with opCmp it looks like operator overloading abuse to me.

Well, but FuzzyNumbers are fuzzy sets that are treated like scalars in a pragmatic, but imperfect way. It makes sense to state that a vivid design A is both uglier and prettier than a boring and dull design B.

I think opCmp is a mistake once you move beyond real scalars. Defining sort order is a separate "tool". Take for instance complex numbers that can be ordered by magnitude, but you need to account for phase (in some arbitrary way since it is circular) to get total order. That does not mean that one should use the sort-comparison for non-sort comparison of complex numbers.

On Thursday, 24 July 2014 at 08:18:22 UTC, Daniel Gibson wrote:
> When I implement the "comparison operator" for my type, I expect it to be used for comparisons - and that includes equality.
> If I had the feeling that I could implement == in a more efficient way, or that I actually want equality to have different semantics, I'd just implement opEquals as well.
>
> IMHO, everything else would be just confusing to the "average" user, and if someone wants to be confused by counterintuitive rules (however much sense they may make in some way) he could as well just use C++ instead.
>
> But if the general view really is that opEquals should *not* be opCmp == 0 by default, for performance reasons or whatever, then please enforce defining opEquals when opCmd is defined, so it's at least explicit that opCmd does not define equality.

+1

Silently breaking (IMHO reasonable) expectations is bad.