A fresh look at comparisons

[Bruno Medeiros]

Janice Caron wrote:
> 
> And it gets worse. For complex numbers we (correctly) have the following result:
> 
>     cdouble x = 1;
>     cdouble y = 1i;
> 
>     (x !<>= y) == true
> 
> Try doing that with a custom type! The problem is, opCmp() just isn't
> powerful enough. With opCmp, there is no way to say "not less than,
> not equal to, and not greater than".
> 
> I think it's time to take a fresh look at comparisons, and to realise
> that comparison is /special/, in much the same way that a constructor
> is special. It shouldn't be a regular function. It should be a special
> function, with its own special syntax, and some extra special rules
> that make it (1) easy to write, (2) logical, and (3) behave sensibly.
> 

You say:
" The problem is, opCmp() just isn't powerful enough. With opCmp, there 
is no way to say "not less than, not equal to, and not greater than" "

I don't mean offense, but I find such idea ridiculous! opCmp is a 
mechanism for defining the ordering in types that have have full 
ordering. What's the problem there? Why should it be extended to support 
something more? Your proposal added more complicated syntax and 
semantics to D to support comparison for types that don't have full 
ordering (like complex numbers), but such use cases are very specific 
and uncommon. And that's why I find the idea of complicating the 
language to support them very unlikable.
Furthermore, while the semantics of full ordering are the same for all 
types that support it, the semantics of partial ordering might not be. 
For example, the comparison operators for complex types might not be 
quite applicable for other kinds of partial ordering mathematical types 
(I wish I was a mathematician so I could remember a concrete example).
No, this is the kind of stuff that should be handled with plain member 
functions.

And this same logic applies to complex types themselves: I think that 
complex types (and their specific operators) should be a library type 
instead of a built-in type, and their specific comparison operators 
should be member functions. Walter has been thinking about this, and 
hopefully he will go forward with it.

-- 
Bruno Medeiros - MSc. in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D