On Saturday, 26 July 2014 at 13:25:06 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 10:22:54 UTC, Fool wrote:
It needs to be defined what kind of relation opCmp is meant to
model.
If it's concept is a partial order, opEquals cannot be
inferred.
If it's concept is a strict weak ordering [1, 2], which is
required for sorting, opEqual can be inferred.
I don't think so.
NaN < x is false
NaN > x is false
...which means that < as it is usually defined on floating point
numbers does not define a strict weak ordering.
This suggests that opCmp should not be required to model a
(strict) weak ordering. On the other hand this means that sorting
is not defined by opCmp.
The last fact is documented at
http://dlang.org/phobos/std_algorithm.html#sort
if you try to derive equality from that you would get:
NaN == x is true
This is not a contradiction to what I wrote.
For sorting you are obviously better off defining NaN as in a
manner that is consistent with the other values of the type.
E.g. preceding all other float values.
...which means that you are extending the partial order to a
particular total order.
