Should clone take &mut self?

[brson]

There are plenty of types that need to do record keeping during clone. Don't see an issue for this.

[thestinger]

I don't think it should, because it would become much less useful in generic functions. Most of the types needing to do record keeping are going to be doing it through a type with inherent mutability like *mut (reference counting).

[lilyball]

If clone takes &mut self, how would you ever clone an immutable value?

[thestinger]

Heh, I wasn't even thinking about that. We should probably just have an alternate way of cloning things when it requires mutation. Since Clone is just a normal trait in the standard library it doesn't really have to cover all use cases.

[nikomatsakis]

What are some examples of types that need record keeping? @thestinger mentioned reference counting (i.e., ARC, RC). Are there others?

I tend to think of our type system as sometimes ruling out potential designs (i.e., mutable fields in C++) because their safety cannot be automatically verified, and I'm ok with that, so long as the set of designs is... not too large. (The option of unsafe code is there too, of course)

[thestinger]

I think it's clear that we're not going to be able to make Clone take &mut self. If we end up with a significant number of these, we should consider making a separate trait, but we can just use a non-trait method for now.