What is the point of `impl Clone for &'a T`?

Until I saw this Internals post, I didn't realize that references implemented clone().

This is not merely an accident of the language syntax, or anything like that; the implementation is here.

This seems like it can only lead to confusion; for instance, in this example, forgetting #[derive(Clone)] on struct Foo doesn't even trigger Clippy's lint for clone-on-&&_!

So, is there some case I'm not thinking of in which it's actually helpful to have all refs implement clone()?

&T is Copy, and therefore, must also be Clone.

4 Likes

...well, I can't argue with that!

...can you think of any reason why a lint on #[derive(Clone)] deriving &&_.clone() would be problematic? If not, that seems like a new Clippy lint I'd like to suggest.

I'm not sure what you mean to show with this example -- even if Foo implements Clone, Bar::clone() will still only clone (copy) the reference. There's no way for it to create a new owned Foo.

1 Like

I honestly hadn't thought of that, but of course you're right--the lifetime system would never permit that.

Anything generic on T: Clone, like Vec::resize.

1 Like