define Ord as a total ordering and remove the f32/f64 implementation (similarly, remove the Eq implementation)

[thestinger]

The operators will still work, because they are a language feature. This would remove the need for TotalEq and TotalOrd. The current situation is too complex and traits without requirements aren't good traits. These do need some kind of definition, whether it's a total ordering or a weak ordering.

Floating point types could still implement these via the IEEE754 total ordering predicate. For equality, it will be as fast as it's just a bitwise comparison. It looks like there's no way to avoid a performance hit for comparisons, but the traditional weak ordering can still be provided via alternate methods.

[nikomatsakis]

One implication of this is that you could not sort an array of floats

[nikomatsakis]

We could add PartialEq and PartialOrd and make Eq and Ord total

[pnkfelix]

Need to discuss further. accepted for 1.0. P-backcompat-lang.

[thestinger]

@nikomatsakis: You wouldn't be able to use a sort method based on Ord, but passing a closure to a more flexible sort method would work and I think we'll want that flexibility available anyway.

[thestinger]

There's now a sort_by method so floats won't be left without an array sorting method. Deciding how to order NaN becomes the problem of the code calling sort_by.

[huonw]

FWIW, [].sort() currently uses TotalOrd so sorting an array of floats already requires using a closure with .sort_by().

[nikomatsakis]

One thought: Why is it so hard to implement Ord for f32 and f64? That is, we can define a total ordering (e.g., borrowing the definition that Java uses). It does mean that the < operator will not necessarily be the same as the Ord trait. I used to think this was awful but I think I've personally come to terms with it.

[nikomatsakis]

I guess this does not work as well for Eq unless we define the operator == to be some other trait.

[thestinger]

@nikomatsakis: I think it would be quite strange for < to do a different operation in a generic function for floating point numbers. IEEE754 does define a total order for floating point numbers but I think using it would be a performance hit for the ordering functions (although not equality).

[thestinger]

I think doing this is incredibly important. A sane definition of equality and ordering is required for these traits to be useful for writing correct generic code. If having these for floating point numbers is viewed as important, then we should to implement the IEEE754 total ordering for the built-in comparison operations and these traits. The traditional partial ordering can be provided via a separate set of methods.

Without defined requirements, traits are the worst of both worlds. They're more verbose than generics without bounds and aren't enforcing a set of requirements on the type parameters.