External Publication
Visit Post

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

Rust Internals [Unofficial] June 5, 2026
Source

SkiFire13:

adding impl Clone for Foo<NonClone> would be a breaking change because it silently disables the existing Clone impl.

It wouldn't be silent. You will immediately get a compile error "the trait Clone is not implemented for Foo<T>", because Clone is super trait of Copy. Now you have two choices:

  1. Add a derive(Clone): No breaking change at all.
  2. Do something else, like impl<T: Copy> Clone for Foo<T>, which would be breaking change, but you explicitly opted-in.

So, at least in your current example, I don't think there is any increased semver risk added by this feature.

SkiFire13:

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

You are right. implied_bounds are implicit in another dimension, but my point that T: Copy has an implicit Clone bound is unchanged, other than wording.

SkiFire13:

you'll get by changing Clone itself

What do you mean by changing Clone?

Discussion in the ATmosphere

Loading comments...