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.
