clone_from in the standard library

[Aatch]

The Clone trait has a sadly-neglected clone_from method that clones a value into an existing one. There is a default implementation, but it's fairly naive and therefore not optimal for all cases, notably collections.

It would be good if the major collections had better implementations for clone_from where it can be implemented more efficiently.

/cc @rust-lang/libs

[sfackler]

Seems pretty reasonable to me. We might also want to consider updating deriving logic to implement clone_from explicitly

[petrochenkov]

cc #27939

[alexcrichton]

My thoughts here are that one-off specialized implementations are fine, but I'm not a huge fan of altering derive(Clone)] (e.g. see my comments on #27939). In that sense I'm fine just updating Clone implementations in-tree for collections to "do the right thing"

[apasel422]

• BinaryHeap
• BTreeMap
• BTreeSet
• HashMap
• HashSet
• LinkedList
• String
• Vec
• VecDeque
• Option
• Result

[bluss]

Edited the list to add Option and Result

[steveklabnik]

Triage: the above list is still accurate today.

[jonas-schievink]

Seems like a good issue for people who want to work on libstd

[m-ou-se]

@apasel422 You can update your comment to check Option and Result. :)

[AnthonyMikh]

Do we currently have any specific requirements to field drop order for this method? The docs are too vague. This can actuallly cause problems. For example, the following code:

#[derive(Clone)]
struct A;

impl Drop for A {
    fn drop(&mut self) {
        println!("A dropped");
    }
}

#[derive(Clone)]
struct B;

impl Drop for B {
    fn drop(&mut self) {
        println!("B dropped");
    }
}

struct Pair {
    a: A,
    b: B,
}

impl Clone for Pair {
    fn clone(&self) -> Self {
        Pair {
            a: self.a.clone(),
            b: self.b.clone(),
        }
    }
    
    // fn clone_from(&mut self, other: &Self) {
    //     self.b = other.b.clone(); // <-- note: assigned in other order
    //     self.a = other.a.clone();
    // }
}

fn main() {
    let mut first = Pair { a: A, b: B };
    let second = Pair { a: A, b: B };
    first.clone_from(&second);
}

prints:

A dropped
B dropped
A dropped
B dropped
A dropped
B dropped

, but if we uncomment custom implementation of clone_from, then it prints:

B dropped
A dropped
A dropped
B dropped
A dropped
B dropped

This can break the code which relies on specific drop order, so implementing clone_from for the sake of optimisation is actually a breaking change.

[crgl]

@apasel422 you can check BTreeMap, BTreeSet, LinkedList, and VecDeque. I would also argue that since HashMap and HashSet derive from hashbrown (and the benefits of clone_from seem dubious there anyway), this issue could be closed?

[adlerd]

This was marked fixed by @Amanieu in #70052; however, currently std::collections::{HashMap, HashSet}::clone_from use the trait default impl rather than hashbrown::*::clone_from because they #[derive(Clone)]. Is this intentional? If not, perhaps this issue should be reopened for now?

[Amanieu]

Nice catch! It should be pretty simple to resolve though, would you like to create a PR?

[adlerd]

Opened #80400.