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. I argue that it's in the *common* case of linear orderings, where people are more liable to assume (incorrectly, it seems!) that opEquals should default to opCmp()==0 -- and that's the case we should be addressing. Let's not lose sight of the forest for the minority of the trees. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
