I find it kinda nice that it would bring the PartialOrd trait in line with the Ord trait in terms of what it provides (under the proposed system). I may lean towards PartialLess instead of PartialOrdLess in terms of naming.

The default implementations could always be overridden if performance is necessary, so I wouldn't see the concern of the default implementation providing a possibly slow default being too worrisome.

I'm using PartialOrdLess because if the thing at the bottom happens as well, both PartialOrdering and PartialEquality would have a variant named PartialEqual otherwise. If we're not going to add partial_eq then we can drop the Ord from the variants.

Why not just Option<Ordering>?

@glaebhoerl that is currently 2 bytes. (But implementing an optimisation like rust-lang/rust#14540 would fix that small issue.)

@glaebhoerl oh, that's a good idea. I'm not super concerned about a 1 byte difference in representation size. I can't imagine people storing millions of partial ordering results or anything.

I'd prefer to keep an enum around for partial_eq as Option<bool> doesn't seem to carry the same meaning as the PartialEquality enum in my eyes.

I'd prefer to keep an enum around for partial_eq as Option<bool> doesn't seem to carry the same meaning as the PartialEquality enum in my eyes.

I have the same feeling. Something like enum IsItEqual { DefinitelyEqual, DefinitelyInequal } and then you can put that in an Option for great symmetry.

Updated in line with @glaebhoerl's comments.

Here's an example of use of partial_cmp to help with some nontrivial PartialOrd impls: rust-postgres/rust-postgres@21feed4

We decided to accept this RFC, discussed in today's meeting