←back to thread

# [derive(Clone)] Is Broken

(rgbcu.be)
128 points RGBCube | 1 comments | 04 Jul 25 20:31 UTC | HN request time: 0.201s | source
Show context
jhugo ◴[08 Jul 25 09:16 UTC] No.44498376[source]▶
> we cannot just require all generic parameters to be Clone, as we cannot assume they are used in such a way that requires them to be cloned.

No, this is backwards. We have to require all generic parameters are Clone, as we cannot assume that any are not used in a way that requires them to be Clone.

> The reason this is the way it is is probably because Rust's type system wasn't powerful enough for this to be implemented back in the pre-1.0 days. Or it was just a simple oversight that got stabilized.

The type system can't know whether you call `T::clone()` in a method somewhere.

replies(4): >>44498401 #>>44498749 #>>44499040 #>>44499325 #
enricozb ◴[08 Jul 25 10:35 UTC] No.44498749[source]▶
For structs, why couldn't rust check the necessary bounds on `T` for each field to be cloned? E.g. in

    #[derive(Clone)]
    struct Weird<T> {
      ptr: Arc<T>,
      tup: (T, usize)
    }
for `ptr`, `Arc<T>: Clone` exists with no bound on `T`. But for `tup`, `(T, usize): Clone` requires `T: Clone`.

Same thing for other derives, such as `Default`.

replies(1): >>44498755 #
jhugo ◴[08 Jul 25 10:37 UTC] No.44498755[source]▶
Because it doesn't know if you're relying on T being Clone in method bodies. The internal behavior of methods is not encoded in the type system.
replies(3): >>44498847 #>>44499243 #>>44508105 #
1. enricozb ◴[09 Jul 25 10:05 UTC] No.44508105[source]▶
I'm not sure how these two things are related. When writing an `impl` for a struct, there's no assumption on the bounds of the generics (if any) unless they are specified _at the impl site_.

For example, the bounds of T in

    impl<T> Weird<T> {
      ..
    }
are independent of the bounds of `T` in any other impl or the struct definition.

Unless I'm missing something...