use correct naming for the comparison traits and add trait inheritance

[thestinger]

Updated description

The target end point: https://gist.github.com/alexcrichton/10945968

Original issue

• rename Ord -> PartialOrd
• rename TotalOrd -> Ord
• rename Eq -> PartialEq
• rename TotalEq -> Eq
• PartialOrd inherits from PartialEq
• Ord inherits from Eq
• Ord inherits from PartialOrd
• Eq inherits from PartialEq
• remove equals method (TotalEq deriving needs to be redone)
• deriving Ord also derives PartialOrd
• deriving Eq also derives PartialEq

An implementation of Eq will simply mean that the PartialEq implementation provides equivalence rather than partial equivalence. An Ord implementation will add a single cmp method and the guarantee of the PartialOrd implementation providing a total order.

This allows code generic over Float to use the operators, since it will inherit from PartialEq and PartialOrd. Code generic over Eq and Ord will also be able to use the operators, despite not being designed to handle a partial order.

[nikomatsakis]

We had some discussion about this on IRC. I think this option is probably the best compromise.

(For my own reference, and to summarize other bugs, iiuc there are 3 fundamental options:

1. All total ordered.
2. Types may implement both partially and totally ordered traits, and the behavior of those traits may different.
3. The totally ordered traits do not define additional methods but simply imply additional laws governing the same methods of the partially ordered traits. That is, the ordering for a single type must be consistent. Implies that f32 and f64 do not implement Ord but only PartialOrd, and hence implies some kind of newtyped float types.

I think Option 3 is probably a good compromise between total principle (option 1) and total pragmatism (option 2), and I think that Option 3 is what this proposal is about.)

[pnkfelix]

@thestinger So you decided not to use the name Cmp for the comparison operator defining trait after all? What changed your mind after writing this comment?

[glaebhoerl]

Might it be worth adding an explicit

partial_cmp(&self, other: &Self) -> Option<Ordering>;

to PartialOrd?

For symmetry, you could also mirror this structure on the Eq side (add enum DefiniteEq { DefinitelyEqual, DefinitelyInequal }, fn Eq::def_eq -> DefiniteEq, fn PartialEq::partial_def_eq -> Option<DefiniteEq> - not with these names), but maybe that's too elaborate.

The motivation in either case is that it's way more obvious from the types that it's a partial ordering/equality (or rather, what is meant by "partial") if there's a method that returns an Option.

[thestinger]

@pnkfelix: I couldn't think of a corresponding name for Eq and I think this is more clear.

@glaebhoerl: It might be worth adding something like that, but for now I just want to land the simplifications and then figure out how to even approach renaming due to deriving.

[pnkfelix]

Assigning 1.0, P-backcompat-libs. What is outlined here is better than what we have now, so it is fine to continue down this path.

(I just want to add the caveat that for 1.0, we will not necessarily adopt this particular strategy for resolving this problem in the end, but we do need to resolve how we are dealing with this problem before 1.0.)