←back to thread

# [derive(Clone)] Is Broken

(rgbcu.be)
128 points RGBCube | 2 comments | 04 Jul 25 20:31 UTC | HN request time: 0.42s | source
Show context
csomar ◴[08 Jul 25 07:53 UTC] No.44497997[source]▶
Derive Clone is not broken. It is basic. I’d say this is a good area for a dependency but not the core Rust functionality. Keep derive simple and stupid, so people can learn they can derive stuff themselves. It also avoids any surprises.
replies(3): >>44498105 #>>44498162 #>>44498173 #
josephg ◴[08 Jul 25 08:14 UTC] No.44498105[source]▶
I disagree. I think the current behaviour is surprising. The first time I ran into this problem, I spent half an hour trying to figure out what was wrong with my code - before eventually realising its a known problem in the language. What a waste of time.

The language & compiler should be unsurprising. If you have language feature A, and language feature B, if you combine them you should get A+B in the most obvious way. There shouldn't be weird extra constraints & gotchas that you trip over.

replies(3): >>44498184 #>>44498204 #>>44498538 #
1. mrbook22 ◴[08 Jul 25 08:37 UTC] No.44498204[source]▶
skill issue. Arc should allow Clone, even if the underlying is not `impl Clone`.
replies(1): >>44499406 #
2. saghm ◴[08 Jul 25 12:40 UTC] No.44499406[source]▶
Arc _does_ allow clone without the underlying implementation not being clone. That's exactly why it's so unexpected that having an `Arc<T>` field in a struct doesn't allow deriving clone unless `T` is also clone; it doesn't actually matter to the implementation, and you end up having to write the exact same thing manually that would be generated by deriving it if the compiler actually allowed it.