Until I saw this Internals post, I didn’t realize that references implemented
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
&T is Copy, and therefore, must also be Clone.
…well, I can’t argue with that!
…can you think of any reason why a lint on
&&_.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
Bar::clone() will still only clone (copy) the reference. There’s no way for it to create a new owned
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