WAT: opCmp and opEquals woes

[via Digitalmars-d]

On Friday, 25 July 2014 at 13:44:54 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> Exactly!! I don't understand why people keep bringing up 
> non-linear
> partial orderings -- those only apply in a *minority* of cases!

Well, if <, <= etc are only to be used where you have a "natural" 
total order then I guess you are right, but then opCmp should be 
limited to those types.

Since comparison and boolean operators (&& etc) cannot be defined 
in a general manner that will work with all branches of 
mathematics, maybe they should be limited to total orders.

It is awfully limiting for DSL-style programming, though. As I've 
pointed out before, how D limits && and || prevents readable 
fuzzy logic and opCmp prevents useful fuzzy number operators. So, 
since the limits are there already, maybe forbidding orders on 
complex types, and vectors etc is sensible too… (Why limit some 
types and not others?)

> 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

It is quite common to want an order on domain-specific objects 
without discriminating all cases, unless you do direct comparison 
for equality. Say if you have a colour type you might want an 
order on chromacity, but not on intensity. If you have a vector, 
you might want an order on magnitude, but not on direction. If 
you have a normal vector you might want an order on acute angles, 
e.g. define a<b === is_acute_angle(a,b).

If opCmp automatically defines equality, then you have to 
remember to undefine it.  Equality as opCmp would be slow and 
wrong in the case of "order by magnitude":

(a.x*a.x + a.y*a.y) == (b.x*b.x + b.y*b.y)

This can go undetected by the programmer if you use a mixin to 
add "standard operators" or if you don't care about equality in 
the actual type, but it is used for equality comparison in an 
aggregate (a struct that has the type as a field).

A more sensible approach from a correctness viewpoint is to 
require equality to be defined explicitly if you provide opCmp. I 
mean, if you want to argue for CORRECTNESS, take it all the way. 
Not 50% convinience, 50% correctness, and a dash flexibility, but 
not quite enough to cover the most pragmatic branches of 
mathematics…