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…
