{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia2aqpkn4bd7smh226tat3vf4qstbnqamegrbz6pxmbrdfwcrkdau",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnkqi7nwawl2"
  },
  "path": "/t/make-derive-copy-enough-for-both-clone-and-copy/24371#post_13",
  "publishedAt": "2026-06-05T17:09:19.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "HKalbasi:\n\n> PROgrm_JARvis:\n>\n>> Also becoming a potential SemVer hazard\n>\n> Can you please explain this? I don't see any semver risk here.\n\nIf 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.\n\nHKalbasi:\n\n> 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?\n\nThis is not an implied bound, it is a logical implication. `T: Copy` and `Copy: Clone`, hence `T: Clone`.\n\nPROgrm_JARvis:\n\n> Also, can't this be implemented as an external crate with some `#[derive(Clopy)]` to explore the actual usefulness for the ecosystem?\n\nIMO any such experiment will flawed because they do not measure the impact of the breakage you'll get by changing `Clone` itself.",
  "title": "Make `#[derive(Copy)]` enough for both `Clone` and `Copy`"
}