A fresh look at comparisons

[Bill Baxter]

Janice Caron wrote:
> On 14/04/2008, Henning Hasemann <hhasemann at web.de> wrote:
>>  I like this proposal but it might have efficiency issues when you need
>>  to find out quickly if you want to order two values (you would often
>>  have to call both functions).
> 
> 
> The best way to fix the efficiency issue would be to tell the compiler
> whether the comparison was fully ordered or not. If the comparison is
> fully ordered, then the compiler may implement
> 
>     a <= b
> 
> as
> 
>     !(b < a)
> 
> whereas, if the comparison is /not/ fully ordered, then the compiler
> would need to go the long route, and implement it as
> 
>     a == b || a < b
> 
> So the question then becomes, how we tell the compiler whether or not
> a comparison is fully ordered. My suggestion would be, assume yes by
> default, and use a slightly modified syntax if not. e.g.
> 
>     class NotFullyOrdered
>     {
>         int x;
> 
>         is(this < c, unordered)
>         {
>             return whatever;
>         }
>     }
> 
> The default, compiler-generated comparison function, if not supplied
> by the programmer, should be
> 
>         is(this < c, unordered)
>         {
>             /* recursive memberwise comparison */
>         }
> 
> That buys you the best of all worlds.

Why not put the flag as an arg to is--  a la
"cast(extra_arg)"
or
"foreach(extra_arg)(some;stuff)" as Andrei proposed.

So it would be

    is(unordered)(this<c)


I like the ideas you're throwing around here, anyway.  Handling of 
comparisons could use some work.  Writing "multi-column" lexical opCmps 
is also really annoying.

Not to mention wanky-ness about opCmp happily compiling with ref/value/ 
or ptr members but only actually working in all cases when you use value 
parameters.  For sorting, pointer parameters work.   For comparisons in 
regular code ref parameters work.  The whole thing is just badly in need 
of some loving.

--bb