Auto merge of #41009 - scottmcm:toowned-clone-into, r=alexcrichton

Add a resource-reusing method to `ToOwned`

`ToOwned::to_owned` generalizes `Clone::clone`, but `ToOwned` doesn't have an equivalent to `Clone::clone_from`.  This PR adds such a method as `clone_into` under a new unstable feature `toowned_clone_into`.

Analogous to `clone_from`, this has the obvious default implementation in terms of `to_owned`.  I've updated the `libcollections` impls: for `T:Clone` it uses `clone_from`, for `[T]` I moved the code from `Vec::clone_from` and implemented that in terms of this, and for `str` it's a predictable implementation in terms of `[u8]`.

Used it in `Cow::clone_from` to reuse resources when both are `Cow::Owned`, and added a test that `Cow<str>` thus keeps capacity in `clone_from` in that situation.

The obvious question: is this the right place for the method?
- It's here so it lives next to `to_owned`, making the default implementation reasonable, and avoiding another trait.  But allowing method syntax forces a name like `clone_into`, rather than something more consistent like `owned_from`.
- Another trait would allow `owned_from` and could support multiple owning types per borrow type.  But it'd be another single-method trait that generalizes `Clone`, and I don't know how to give it a default impl in terms of `ToOwned::to_owned`, since a blanket would mean overlapping impls problems.

I did it this way as it's simpler and many of the `Borrow`s/`AsRef`s don't make sense with `owned_from` anyway (`[T;1]:Borrow<[T]>`, `Arc<T>:Borrow<T>`, `String:AsRef<OsStr>`...).  I'd be happy to re-do it the other way, though, if someone has a good solution for the default handling.

(I can also update with `CStr`, `OsStr`, and `Path` once a direction is decided.)

0 files changed, 0 insertions, 0 deletions