On Friday, 25 July 2014 at 13:44:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 12:10:31PM +0100, Regan Heath via
Digitalmars-d wrote:
On Fri, 25 Jul 2014 09:39:11 +0100, Walter Bright
<[email protected]> wrote:
>On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
>>3. If opCmp is defined but no opEquals, lhs == rhs will be
>>lowered
>>to lhs.opCmp(rhs) == 0
>
>This is the sticking point. opCmp and opEquals are separate on
>purpose, see Andrei's posts.
Sure, Andrei makes a valid point .. for a minority of cases.
The
majority case will be that opEquals and opCmp==0 will agree.
In those
minority cases where they are intended to disagree the user
will have
intentionally defined both, to be different. I cannot think
of any
case where a user will intend for these to be different, then
not
define both to ensure it.
[...]
Exactly!! I don't understand why people keep bringing up
non-linear
partial orderings -- those only apply in a *minority* of cases!
(Raise
your hands if your code depends on non-linear partial
orderings. How
many of you *require* this more often than linear orderings?
Yeah, I
thought so.) Why are we sacrificing *common* case -- where
opCmp defines
a linear ordering -- for the minority case?
And it's not like we're making it impossible in the minority
case -- if
you want a non-linear partial ordering, wouldn't you make sure
to define
both opCmp and opEquals so that they do the right thing? Since
it's an
uncommon use case, people would tend to be more careful when
implementing it.
Do I miss something or wouldn't an non-linear ordering imply,
that x.opCmp(y) != 0 for all x,y ∈ T and thus automatically
generating opEquals to opCmd() == 0 would automatically do the
right thing in this case?
So the amount of people that require a different opEquals are
even smaller
and defining opEquals and opCmp for two different orderings is a
code smell squared.
