# Trait core::cmp::PartialOrd

1.0.0 · source · ```
pub trait PartialOrd<Rhs: ?Sized = Self>: PartialEq<Rhs> {
// Required method
fn partial_cmp(&self, other: &Rhs) -> Option<Ordering>;
// Provided methods
fn lt(&self, other: &Rhs) -> bool { ... }
fn le(&self, other: &Rhs) -> bool { ... }
fn gt(&self, other: &Rhs) -> bool { ... }
fn ge(&self, other: &Rhs) -> bool { ... }
}
```

## Expand description

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:

`a == b`

if and only if`partial_cmp(a, b) == Some(Equal)`

.`a < b`

if and only if`partial_cmp(a, b) == Some(Less)`

`a > b`

if and only if`partial_cmp(a, b) == Some(Greater)`

`a <= b`

if and only if`a < b || a == b`

`a >= b`

if and only if`a > b || a == b`

`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 `impl`

s that allow comparing `T < U`

. In
other words, if other crates add `impl`

s 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 `impl`

s that “stitch together” comparisons of foreign types in ways that violate
transitivity.

Not having such foreign `impl`

s 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);
```

Run### §Derivable

This trait can be used with `#[derive]`

.

When `derive`

d on structs, it will produce a
lexicographic ordering
based on the top-to-bottom declaration order of the struct’s members.

When `derive`

d on enums, variants are primarily ordered by their discriminants.
Secondarily, they are ordered by their fields.
By default, the discriminant is smallest for variants at the top, and
largest for variants at the bottom. Here’s an example:

```
#[derive(PartialEq, PartialOrd)]
enum E {
Top,
Bottom,
}
assert!(E::Top < E::Bottom);
```

RunHowever, manually setting the discriminants can override this default behavior:

```
#[derive(PartialEq, PartialOrd)]
enum E {
Top = 2,
Bottom = 1,
}
assert!(E::Bottom < E::Top);
```

Run### §How can I implement `PartialOrd`

?

`PartialOrd`

only requires implementation of the `partial_cmp`

method, 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).

`PartialOrd`

requires your type to be `PartialEq`

.

If your type is `Ord`

, you can implement `partial_cmp`

by using `cmp`

:

```
use std::cmp::Ordering;
#[derive(Eq)]
struct Person {
id: u32,
name: String,
height: u32,
}
impl PartialOrd for Person {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl Ord for Person {
fn cmp(&self, other: &Self) -> Ordering {
self.height.cmp(&other.height)
}
}
impl PartialEq for Person {
fn eq(&self, other: &Self) -> bool {
self.height == other.height
}
}
```

RunYou may also find it useful to use `partial_cmp`

on your type’s fields. Here
is an example of `Person`

types who have a floating-point `height`

field that
is the only field to be used for sorting:

```
use std::cmp::Ordering;
struct Person {
id: u32,
name: String,
height: f64,
}
impl PartialOrd for Person {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
self.height.partial_cmp(&other.height)
}
}
impl PartialEq for Person {
fn eq(&self, other: &Self) -> bool {
self.height == other.height
}
}
```

Run## §Examples

```
let x: u32 = 0;
let y: u32 = 1;
assert_eq!(x < y, true);
assert_eq!(x.lt(&y), true);
```

Run## Required Methods§

source#### fn partial_cmp(&self, other: &Rhs) -> Option<Ordering>

#### fn partial_cmp(&self, other: &Rhs) -> Option<Ordering>

This method returns an ordering between `self`

and `other`

values if one exists.

##### §Examples

```
use std::cmp::Ordering;
let result = 1.0.partial_cmp(&2.0);
assert_eq!(result, Some(Ordering::Less));
let result = 1.0.partial_cmp(&1.0);
assert_eq!(result, Some(Ordering::Equal));
let result = 2.0.partial_cmp(&1.0);
assert_eq!(result, Some(Ordering::Greater));
```

RunWhen comparison is impossible:

```
let result = f64::NAN.partial_cmp(&1.0);
assert_eq!(result, None);
```

Run## Provided Methods§

## Implementors§

### impl PartialOrd for AsciiChar

### impl PartialOrd for Infallible

### impl PartialOrd for IpAddr

### impl PartialOrd for SocketAddr

### impl PartialOrd for Ordering

### impl PartialOrd for bool

### impl PartialOrd for char

### impl PartialOrd for f32

### impl PartialOrd for f64

### impl PartialOrd for i8

### impl PartialOrd for i16

### impl PartialOrd for i32

### impl PartialOrd for i64

### impl PartialOrd for i128

### impl PartialOrd for isize

### impl PartialOrd for !

### impl PartialOrd for str

Implements comparison operations on strings.

Strings are compared lexicographically by their byte values. This compares Unicode code
points based on their positions in the code charts. This is not necessarily the same as
“alphabetical” order, which varies by language and locale. Comparing strings according to
culturally-accepted standards requires locale-specific data that is outside the scope of
the `str`

type.

### impl PartialOrd for u8

### impl PartialOrd for u16

### impl PartialOrd for u32

### impl PartialOrd for u64

### impl PartialOrd for u128

### impl PartialOrd for ()

### impl PartialOrd for usize

### impl PartialOrd for TypeId

### impl PartialOrd for CpuidResult

**x86 or x86-64**only.

### impl PartialOrd for CStr

### impl PartialOrd for Error

### impl PartialOrd for PhantomPinned

### impl PartialOrd for Ipv4Addr

### impl PartialOrd for Ipv6Addr

### impl PartialOrd for SocketAddrV4

### impl PartialOrd for SocketAddrV6

### impl PartialOrd for Alignment

### impl PartialOrd for Duration

### impl PartialOrd<IpAddr> for Ipv4Addr

### impl PartialOrd<IpAddr> for Ipv6Addr

### impl PartialOrd<Ipv4Addr> for IpAddr

### impl PartialOrd<Ipv6Addr> for IpAddr

### impl<'a> PartialOrd for Location<'a>

### impl<A, B: ?Sized> PartialOrd<&B> for &Awhere
A: PartialOrd<B> + ?Sized,

### impl<A, B: ?Sized> PartialOrd<&mut B> for &mut Awhere
A: PartialOrd<B> + ?Sized,

### impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn>

### impl<F: FnPtr> PartialOrd for F

### impl<Ptr: Deref, Q: Deref> PartialOrd<Pin<Q>> for Pin<Ptr>

### impl<T> PartialOrd for (T₁, T₂, …, Tₙ)where
T: ?Sized + PartialOrd,

This trait is implemented for tuples up to twelve items long.

### impl<T> PartialOrd for NonZero<T>where
T: ZeroablePrimitive + PartialOrd,

### impl<T, const N: usize> PartialOrd for Mask<T, N>

### impl<T, const N: usize> PartialOrd for Simd<T, N>

### impl<T: PartialOrd + Copy> PartialOrd for Cell<T>

### impl<T: PartialOrd + ?Sized> PartialOrd for ManuallyDrop<T>

### impl<T: PartialOrd> PartialOrd for Option<T>

### impl<T: PartialOrd> PartialOrd for Poll<T>

### impl<T: PartialOrd> PartialOrd for [T]

Implements comparison of vectors lexicographically.