Trait for types that form a partial order.

The lt, le, gt, and ge methods of this trait can be called using the <, <=, >, and >= operators, respectively.

The methods of this trait must be consistent with each other and with those of [PartialEq]. The following conditions must hold:

1. a == b if and only if partial_cmp(a, b) == Some(Equal).
2. a < b if and only if partial_cmp(a, b) == Some(Less)
3. a > b if and only if partial_cmp(a, b) == Some(Greater)
4. a <= b if and only if a < b || a == b 5. a >= b if and only if a > b || a == b
5. a != b if and only if !(a == b).

Conditions 2–5 above are ensured by the default implementation. Condition 6 is already ensured by [PartialEq].

If [Ord] is also implemented for Self and Rhs, it must also be consistent with partial_cmp (see the documentation of that trait for the exact requirements). It's easy to accidentally make them disagree by deriving some of the traits and manually implementing others.

The comparison relations must satisfy the following conditions (for all a, b, c of type A, B, C):

• Transitivity: if A: PartialOrd<B> and B: PartialOrd<C> and A: PartialOrd<C>, then a < b and b < c implies a < c. The same must hold for both == and >. This must also work for longer chains, such as when A: PartialOrd<B>, B: PartialOrd<C>, C: PartialOrd<D>, and A: PartialOrd<D> all exist.
• Duality: if A: PartialOrd<B> and B: PartialOrd<A>, then a < b if and only if b > a.

Note that the B: PartialOrd<A> (dual) and A: PartialOrd<C> (transitive) impls are not forced to exist, but these requirements apply whenever they do exist.

Violating these requirements is a logic error. The behavior resulting from a logic error is not specified, but users of the trait must ensure that such logic errors do not result in undefined behavior. This means that unsafe code must not rely on the correctness of these methods.

Cross-crate considerations

Upholding the requirements stated above can become tricky when one crate implements PartialOrd for a type of another crate (i.e., to allow comparing one of its own types with a type from the standard library). The recommendation is to never implement this trait for a foreign type. In other words, such a crate should do impl PartialOrd<ForeignType> for LocalType, but it should not do impl PartialOrd<LocalType> for ForeignType.

This avoids the problem of transitive chains that criss-cross crate boundaries: for all local types T, you may assume that no other crate will add impls that allow comparing T < U. In other words, if other crates add impls that allow building longer transitive chains U1 < ... < T < V1 < ..., then all the types that appear to the right of T must be types that the crate defining T already knows about. This rules out transitive chains where downstream crates can add new impls that "stitch together" comparisons of foreign types in ways that violate transitivity.

Not having such foreign impls also avoids forward compatibility issues where one crate adding more PartialOrd implementations can cause build failures in downstream crates.

Corollaries

The following corollaries follow from the above requirements:

• irreflexivity of < and >: !(a < a), !(a > a)
• transitivity of >: if a > b and b > c then a > c
• duality of partial_cmp: partial_cmp(a, b) == partial_cmp(b, a).map(Ordering::reverse)

Strict and non-strict partial orders

The < and > operators behave according to a strict partial order. However, <= and >= do not behave according to a non-strict partial order. That is because mathematically, a non-strict partial order would require reflexivity, i.e. a <= a would need to be true for every a. This isn't always the case for types that implement PartialOrd, for example:

let a = f64::sqrt(-1.0);
assert_eq!(a <= a, false);

How can I implement PartialOrd?

PartialOrd only requires implementation of the PARTIAL_CMP protocol, with the others generated from default implementations.

However it remains possible to implement the others separately for types which do not have a total order. For example, for floating point numbers, NaN < 0 == false and NaN >= 0 == false (cf. IEEE 754-2008 section 5.11).

PARTIAL_CMP requires your type to be [PARTIAL_EQ].

If your type is [ORD], you can implement PARTIAL_CMP by using CMP.

You may also find it useful to use PARTIAL_CMP on your type's fields.

Examples

let x = 0;
let y = 1;

assert_eq!(x < y, true);
assert_eq!(x.lt(y), true);