Why does im_rc::Vector .iter() require Copy?

[anon80458984]

Here, ImVec refers to im_rc::Vector.

In the following code:

pub struct FooBar {}

fn blah(lst: ImVec<FooBar>) {
    let t = lst.iter().map(|x| ());
}

I get compile error of:

   |
83 |     let t = lst.iter().map(|x| ());
   |                 ^^^^
   |
   = note: the method `iter` exists but the following trait bounds were not satisfied:
           `worp_vm::worp_runtime_err::FooBar : std::clone::Clone`

This confuses me. The map function is passed x: &FooBar as a ref -- so why do we need FooBar to have clone ?

[Yandros]

It looks like all their data structures require Clone to ever do anything with it.

To be honest I think they should have required Clone only on &mut self methods, since according to their documentation, that's the only time where actual cloning may happen (Copy-on-Write):

@https://docs.rs/im/13.0.0/im/

When does cloning happen?

So when will your values actually be cloned? The easy answer is only if you clone the data structure itself, and then only lazily as you change it. Values are stored in tree nodes inside the data structure, each node of which contains up to 64 values. When you clone a data structure, nothing is actually copied - it's just the reference count on the root node that's incremented, to indicate that it's shared between two data structures. It's only when you actually modify one of the shared data structures that nodes are cloned: when you make a change somewhere in the tree, the node containing the change needs to be cloned, and then its parent nodes need to be updated to contain the new child node instead of the old version, and so they're cloned as well.

We can call this "lazy" cloning - if you make two copies of a data structure and you never change either of them, there's never any need to clone the data they contain. It's only when you start making changes that cloning starts to happen, and then only on the specific tree nodes that are part of the change. Note that the implications of lazily cloning the data structure extend to memory usage as well as the CPU workload of copying the data around - cloning an immutable data structure means both copies share the same allocated memory, until you start making changes.

Most crucially, if you never clone the data structure, the data inside it is also never cloned, and in this case it acts just like a mutable data structure, with minimal performance differences (but still non-zero, as we still have to check for shared nodes).

---

(or at least they should have added a A : Clone bound on the type definitions themselves, so as to make the "you need Clone for absolutely everything" intent clearer)