WAT: opCmp and opEquals woes

[Fool via Digitalmars-d]

On Sunday, 27 July 2014 at 00:43:40 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> https://github.com/D-Programming-Language/dlang.org/pull/620

Thank you for this.

There is still a problem, I think.

Defining opEquals only makes sense if a user wants to replace 
equality by some equivalence relation (different from equality).

The user is not forced to define opEquals such that it models an 
equivalence relation but it hardly makes sense.

Similarly, the user is free to define opCmp without restriction. 
In practice, however, it does not seem to make any sense if <= 
does not even model a preorder (reflexive and transitive) or one 
of >, <=, < does not match.

It turns out that intuition of many people around here is not at 
random. Let A be a set and <= a preorder on A. For all a, b in A 
define ~ such that a ~ b = (a <= b or b <= a). Then ~ is an 
equivalence relation. (Let me know if you need a proof.)

Clearly, it is possible to define different equivalence relations 
on a set. The same is true for orderings.

Now opEquals and opCmp are used to define a default equivalence 
relation and ordering on a type, respectively.

Please excuse my lack of creativity: in presence of opCmp I 
cannot see a single sensible use case for defining a.opEquals(b) 
different from a.opCmp(b) == 0.

Those examples mentioned before are skewed.

If a candidate for opCmp does not match the default equivalence 
relation == (defined implicitly or explicitly specified using 
opEquals) it should not be defined at all.