WAT: opCmp and opEquals woes

[via Digitalmars-d]

On Friday, 25 July 2014 at 20:13:57 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> Nobody said anything
> about making it *impossible* to define non-linear orderings.

But opCmp() already make it impossible to define some binary 
relations that are order-like for <, <= etc. You cannot return 
both -1 and 1 at the same time. And >= is defined a the 
complement of <. What does 0 signify, does it signify equality or 
that two values cannot be ordered? Take for instance intervals:

Defining [0,1] < [2,3] makes sense, but should [1,2] vs [0,3] 
give 0, or is that only for [1,2] vs [1,2]?

It makes a lot of sense to provide "sortability traits" for the 
type, such as total-order etc, but then one shouldn't limit the 
implementation of operators like this without tying it to a trait 
of some kind. Either the presence of opCmp is a trait of the 
type, or the trait has to be provided by some other means.

Related to some other comments in the thread, some sort 
algorithms designed for scenarios where you have many similar 
values need equality for proper or efficient sorting. Like 
quicksort implementations where you partition into 3 sets (left, 
pivot-equality, right). On most CPUs you get both less-than and 
equality information from a single compare so how you implement 
opCmp and sorting is crucial for performance…