- 
                Notifications
    
You must be signed in to change notification settings  - Fork 13.9k
 
Closed
Labels
C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
Currently std gives the following example in "How can I implement Ord?":
use std::cmp::Ordering;
#[derive(Eq)]
struct Person {
    id: u32,
    name: String,
    height: u32,
}
impl Ord for Person {
    fn cmp(&self, other: &Self) -> Ordering {
        self.height.cmp(&other.height)
    }
}
impl PartialOrd for Person {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}
impl PartialEq for Person {
    fn eq(&self, other: &Self) -> bool {
        self.height == other.height
    }
}I was wondering why this boilerplate couldn't be reduced, because it seems clear that in almost all cases of Ord implementation, PartialOrd implementation can be done in terms of the former.
I suspect this is in its current state because it exists prior to specialization? If you have the following:
impl<T: Ord> PartialOrd for T {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}Am I right that the std example could be updated to:
use std::cmp::Ordering;
#[derive(Eq)]
struct Person {
    id: u32,
    name: String,
    height: u32,
}
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
    }
}?
Metadata
Metadata
Assignees
Labels
C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.