pub trait PartialOrd<Rhs = Self>: PartialEq<Rhs>where
Rhs: ?Sized,{
// 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.
This trait should only contain the comparison logic for a type if one plans on only
implementing PartialOrd but not Ord. Otherwise the comparison logic should be in Ord
and this trait implemented with Some(self.cmp(other)).
The methods of this trait must be consistent with each other and with those of PartialEq.
The following conditions must hold:
a == bif and only ifpartial_cmp(a, b) == Some(Equal).a < bif and only ifpartial_cmp(a, b) == Some(Less)a > bif and only ifpartial_cmp(a, b) == Some(Greater)a <= bif and only ifa < b || a == ba >= bif and only ifa > b || a == ba != bif 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>andB: PartialOrd<C>andA: PartialOrd<C>, thena < bandb < cimpliesa < c. The same must hold for both==and>. This must also work for longer chains, such as whenA: PartialOrd<B>,B: PartialOrd<C>,C: PartialOrd<D>, andA: PartialOrd<D>all exist. - Duality: if
A: PartialOrd<B>andB: PartialOrd<A>, thena < bif and only ifb > 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
>: ifa > bandb > cthena > 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);§Derivable
This trait can be used with #[derive].
When derived on structs, it will produce a
lexicographic ordering based on the
top-to-bottom declaration order of the struct’s members.
When derived 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);However, manually setting the discriminants can override this default behavior:
#[derive(PartialEq, PartialOrd)]
enum E {
Top = 2,
Bottom = 1,
}
assert!(E::Bottom < E::Top);§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;
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
}
}
impl Eq for Person {}You 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
}
}§Examples of incorrect PartialOrd implementations
use std::cmp::Ordering;
#[derive(PartialEq, Debug)]
struct Character {
health: u32,
experience: u32,
}
impl PartialOrd for Character {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.health.cmp(&other.health))
}
}
let a = Character {
health: 10,
experience: 5,
};
let b = Character {
health: 10,
experience: 77,
};
// Mistake: `PartialEq` and `PartialOrd` disagree with each other.
assert_eq!(a.partial_cmp(&b).unwrap(), Ordering::Equal); // a == b according to `PartialOrd`.
assert_ne!(a, b); // a != b according to `PartialEq`.§Examples
let x: u32 = 0;
let y: u32 = 1;
assert_eq!(x < y, true);
assert_eq!(x.lt(&y), true);Required Methods§
1.0.0 · sourcefn 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));When comparison is impossible:
let result = f64::NAN.partial_cmp(&1.0);
assert_eq!(result, None);Provided Methods§
1.0.0 · sourcefn lt(&self, other: &Rhs) -> bool
fn lt(&self, other: &Rhs) -> bool
Tests less than (for self and other) and is used by the < operator.
§Examples
assert_eq!(1.0 < 1.0, false);
assert_eq!(1.0 < 2.0, true);
assert_eq!(2.0 < 1.0, false);1.0.0 · sourcefn le(&self, other: &Rhs) -> bool
fn le(&self, other: &Rhs) -> bool
Tests less than or equal to (for self and other) and is used by the
<= operator.
§Examples
assert_eq!(1.0 <= 1.0, true);
assert_eq!(1.0 <= 2.0, true);
assert_eq!(2.0 <= 1.0, false);Implementors§
impl PartialOrd for RequestParseStage
impl PartialOrd for IpAddr
impl PartialOrd for SocketAddr
impl PartialOrd for ErrorKind
impl PartialOrd for Ordering
impl PartialOrd for AsciiChar
impl PartialOrd for Infallible
impl PartialOrd for Level
impl PartialOrd for LevelFilter
impl PartialOrd for bool
impl PartialOrd for char
impl PartialOrd for f16
impl PartialOrd for f32
impl PartialOrd for f64
impl PartialOrd for f128
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 Error
impl PartialOrd for Ipv4Addr
impl PartialOrd for Ipv6Addr
impl PartialOrd for SocketAddrV4
impl PartialOrd for SocketAddrV6
impl PartialOrd for Bytes
impl PartialOrd for BytesMut
impl PartialOrd for CompactString
impl PartialOrd for Duration
impl PartialOrd for HeaderValue
impl PartialOrd for Instant
impl PartialOrd for Path
impl PartialOrd for PathBuf
impl PartialOrd for StatusCode
impl PartialOrd for Version
impl PartialOrd for Authority
Case-insensitive ordering
§Examples
let authority: Authority = "DEF.com".parse().unwrap();
assert!(authority < "ghi.com");
assert!(authority > "abc.com");