Make #[derive(Copy, Eq, Ord)] imply #[derive(Clone, PartialEq, PartialOrd)]

[erickt]

This reduces the amount of boilerplate users need to do in order to derive some common traits.

This is related to #23860.

cc @nikomatsakis, @aturon

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[sfackler]

The derived partial_cmp can be optimized in this case to just Some(self.cmp(other)).

EDIT: Hmm, though they're not totally equivalent in the presence of type paramters unfortunately.

[erickt]

Good point. I've got a build running that applies this PartialOrd optimization to non-generic types. I'll push it up when it finishes running.

[aturon]

🎯

[alexcrichton]

Out of curiosity, is it still possible to have #[derive(Ord)] but a manual implementation of PartialOrd?

[sfackler]

@alexcrichton I think the more common thing would be the opposite since PartialOrd has a trivial impl if you've already implemented Ord::cmp.

[alexcrichton]

Hm true. In general I've been very worried in the past about this form of deriving as it seems like a footgun for various forms of configuration of deriving. For example it looks like instances of derive(Eq) with a manual PartialEq impl were removed in favor of a manual Eq impl. I worry about the "half-derive" case, but it may not be too large of a worry in practice. For example adding an impl of Eq is just a marker trait so it's not so bad, and I'm not sure how much this applies to Ord and PartialOrd...

[erickt]

@alexcrichton: with this PR we could no longer provide a manual implementation of PartialOrd with #[derive(Ord)]. Is there ever a case where we'd want a manual implementation if we already have version of Ord? That also seems like it could be a source of bugs if the two were inconsistent.

[nikomatsakis]

My main concern is whether this PR requires an RFC. It seems to be at least mildly controversial. Obviously this would have to land by 1.0 though! (I personally acknowledge @alexcrichton's concerns, but think that this PR is a net improvement on the current situation.)

[erickt]

@sfackler: I just pushed up a patch that simplifies generating PartialOrd for non-generic Ord types. I'm not sure if my metrics are right, but this PR appears to be shaving off about 100KB from libstd.dylib when compared with the latest nightly libstd.dylib, but I can't say if that's all due to this PR or some other optimizations going on. I could do a fresh build to compare the too if we want a real number.

[nikomatsakis]

r+ from me (modulo RFC) but I'm not really that familiar with this code. Certainly I'd like to hear @sfackler or @huonw weigh in.

[bors]

☔️ The latest upstream changes (presumably #23963) made this pull request unmergeable. Please resolve the merge conflicts.

[erickt]

I rebased on top of HEAD to avoid some merge conflicts and squashed some of the cleanup commits together.

[huonw]

Missing Some?

[huonw]

I believe it should be able to made work via the self_args fields of Substructure.

[huonw]

Copying this comment to ensure it doesn't get lost: I believe it one should be able to make the simple-impls work via the self_args fields of Substructure.

Also, another minor point: what about supporting #[derive(Copy, Clone)] struct Foo; (i.e. explicitly write the Clone?)?

Alsoalso, I wonder about the case of optimising PartialOrd (e.g. maybe < can be computed faster than a full comparison). There's a big cliff between:

#[derive(Ord)]
struct Foo { ... }

and

struct Foo { ... }

impl Ord for Foo {
    fn cmp(&self, other: &Foo) -> Ordering {
        // ... lots of stuff ...
    }
}
impl PartialOrd for Foo {
     fn partial_cmp(&self, other: &Foo) -> Option<Ordering> { Some(self.cmp(other)) }
     fn lt(&self, other: &Foo) -> bool { /* supafast */ }
}

That said, it seems like this PR is the right default, and we can add an opt-out mechanism in future.

[nikomatsakis]

Also, another minor point: what about supporting #[derive(Copy, Clone)] struct Foo; (i.e. explicitly write the Clone?)?

I thought the PR did permit this, albeit with a FIXME attached? (I tend to think we should just allow it and, at most, lint for it)

[erickt]

@nikomatsakis: Yes, this PR explicitly handles #[derive(Copy, Clone)]. A lint sounds fine to me.

[huonw]

Oh, I wasn't clear: my reading of the PR was that the support for that was only for staging reasons. In any case, a lint (or nothing) sounds good to me.

[dcrewi]

This should probably be closed now, as the RFC has been resolved?

[alexcrichton]

Yes thanks for the reminder @dcrewi! Closing for the same reasons as listed in the RFC.