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