I have a newtype and I want to implement Ord
:
use std::cmp::{Ord, Ordering};
struct MyType(isize);
impl Ord for MyType {
fn cmp(&self, &other: Self) -> Ordering {
let MyType(ref lhs) = *self;
let MyType(ref rhs) = *other;
lhs.cmp(rhs)
}
}
When I try to compare two variables of my types, I get errors:
error[E0277]: the trait bound `MyType: std::cmp::PartialOrd` is not satisfied
--> src/main.rs:5:6
|
5 | impl Ord for MyType {
| ^^^ can't compare `MyType` with `MyType`
|
= help: the trait `std::cmp::PartialOrd` is not implemented for `MyType`
error[E0277]: the trait bound `MyType: std::cmp::Eq` is not satisfied
--> src/main.rs:5:6
|
5 | impl Ord for MyType {
| ^^^ the trait `std::cmp::Eq` is not implemented for `MyType`
When I implement PartialEq
, Eq
and PartialOrd
(gt()
, lt()
, eq()
, ge()
, le()
, etc.), everything works fine, but if I provided cmp
, we can infer functions like lt()
and eq()
! This is redundant! I don't like this!
When looking in the docs, I see this in the definition of Ord
:
pub trait Ord: Eq + PartialOrd<Self>
This looks like the trait inherits from Eq
and PartialOrd
. Why can't the trait provide default implementations for the required methods from the inherited traits using the cmp
function? I don't know how inheritance of traits works and searching turned up nothing useful, but I think this is something that should be possible.
How is this done in Rust? I hope not this way...
For your specific case I'd use
#[derive]
:If you need to special case your
Ord
implementation, you still have to write out that code, there's nothing that can save us there! You can still derive implementations for the other traits, if it makes sense to do so.The other part of your question is ambiguous, so I'll answer it both ways I read it:
Let's look at the docs for
PartialOrd
andOrd
.PartialOrd
says: "The comparison must satisfy antisymmetry and transitivity", whileOrd
says: "types that form a total order". These are math terms and I won't do as good a job as Wikipedia will at describing them.However, we can use floating point numbers as an example. Floats have a special value called
NaN
. Comparing against this value is tricky. For example, all of1.0 < NaN
,1.0 == NaN
and1.0 > NaN
are false! These don't form a total order, but we can still compare one value against another. This is whyPartialOrd
exists - to allow us to compare types like this. incidentally,PartialEq
exists for similar reasons.We can't define
Ord
in terms ofPartialOrd
because we don't have the appropriate guarantees about the underlying types. This is Rust's type system saving us from making a mistake!The problem here is that more types are
PartialOrd
than they areOrd
. If we required everything to beOrd
, then we couldn't have any floating point comparisons, because they don't have a total order, or we'd have to give up on having a total order and losing out on the safety that it provides.However, there have been ideas to automatically do this for
derive
. Proposed RFC 2385 would allow the above code to be reduced to:Note that
PartialOrd
does have default implementations, you only need to implementcmp
. The others are there for ease-of-use or possibly performance reasons.For starters, you can implement only
PartialOrd::partial_cmp
, aslt
,le
,gt
, andge
have default implementations. Furthermore, if you implementOrd
, you can simply implementcmp
as usual andpartial_cmp
becomes justSome(self.cmp(other))
.However, if you only want to delegate to some field's notion of equality and ordering, then it's far better and easier to derive: