I would like to solicit community feedback on a possible breaking change. There has been an RFC (and implementation) to change deriving so that deriving subtraits, like Copy , Ord , and Eq , would imply deriving their respective supertraits.

In other words:

#[derive(Copy)] equivalent to #[derive(Copy, Clone)] #[derive(Ord)] equivalent to #[derive(Ord, PartialOrd, Eq, PartialEq)] #[derive(Eq)] equivalent to #[derive(Eq, PartialEq)]

(Actually, I believe the RFC only says that Ord implies PartialOrd , but I think it makes sense to go the whole way.) The goal here is primarily to reduce the verbosity that is currently required, though it can also allow derive to produce more efficient impls of Clone (since derive would know that the type is also Copy ).

However, this is a breaking change. If you currently use #[derive] to derive (e.g.) Eq , but you manually implement PartialEq , then your code would now fail due to coherence errors. This is because #[derive(Eq)] would now also supply an impl for PartialEq . This is of course relatively easy to fix – either remove the manual impl of PartialEq , or else convert the derive(Eq) into a manual impl.

This has been a long-requested feature. Unfortunately, it didn’t make it into the beta. This means that if we are going to introduce this feature, we have to do it now – or at least we have to wait until we have specialization or some other means for derive to ‘conditionally’ generate these impls.

At this point, the RFC has relatively little feedback – what comments there are are primarily positive, but it would be helpful to get more feedback overall.

In particular: are the improved ergonomics here worth the potential breakage during beta?