Make `#[derive(Copy)]` enough for both `Clone` and `Copy`

HKalbasi:

PROgrm_JARvis:

Also becoming a potential SemVer hazard

Can you please explain this? I don't see any semver risk here.

If you have a #[derive(Copy)] struct Foo<T> that also implements Clone for Foo<T: Clone> then adding impl Clone for Foo<NonClone> would be a breaking change because it silently disables the existing Clone impl.

HKalbasi:

Since the Clone is super trait of Copy, this is similar to implied bounds. Do you consider T: Copy instead of T: Clone + Copy a bad thing, reducing the Rust's intentional explicitness?

This is not an implied bound, it is a logical implication. T: Copy and Copy: Clone, hence T: Clone.

PROgrm_JARvis:

Also, can't this be implemented as an external crate with some #[derive(Clopy)] to explore the actual usefulness for the ecosystem?

IMO any such experiment will flawed because they do not measure the impact of the breakage you'll get by changing Clone itself.