A fresh look at comparisons

[Bruno Medeiros]

Bruno Medeiros wrote:
> 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.
> 

I have just read your new thread "A Fresh Look at Comparisons, Take 2" 
(I've started reading 1400 late posts in digitalmars.D alone, so it's a 
bit confusing...) , and it seems that you converged to this same opinion:


"[...] Library solutions such as
std.algorithm may be able to accept partially ordered sets where
appropriate. But I think that it's such a rare edge-case that having
it built into the language itself is probably unnecessary. After all,
we don't have that now, and I've never seen a complaint about its
absence."

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