Change:
Feature in PR Questions raised in the PR: [ ] The directionality is weird. In clone_from and assignment, the data moves right-to-left, but this moves it left-to-right. And that means that autoref doesn't work well, usually forcing you to write &mut.[ ] But fixing that would mean putting it somewhere else, since the Self in ToOwned is the wrong type for what this needs to be. And moving it while still being overridable and providing a default is hard.
In nightly for 11 months with no reported issues since. Let’s stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Hmm, I was bad at creating tracking issues a year ago :sweatsmile: (fixed) This is sufficient, but still feels suboptimal for the reasons from The directionality is weird. In and assignment, the data moves right-to-left, but this moves it left-to-right. And that means that autoref doesn't work well, usually forcing you to write .But fixing that would mean putting it somewhere else, since the in is the wrong type for what this needs to be. And moving it while still being overridable and providing a default is hard. Any good ideas? Edit: Hmm, maybe once we flatten the (since is in but is in ) then could have ?
concern direction formally registering
The final comment period is now complete.
rfcbot did not register the concern :) (the syntax you used is accepted nowadays however..)
I feel bad seeing this in TWiR every week now. Anything I can do to help it get somewhere productive?
Nominating for discussion (how to address the concern raised in ). ↑.
It looks like this still needs some API some design work, so we’re not actually ready to stabilize. fcp cancel This probably needs someone to champion a new API proposal.
proposal cancelled.
This was discussed in the libs-api meeting just now. We discussed how this method is used in Cow's clone_from implementation, and how that seems to be a good reason to stabilize this function and allow others to imlement it. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Friendly one-month pFCP ping,
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.

Discussion:
/// Basic usage: /// /// ``` <del> /// # #![feature(toowned_clone_into)] </del> /// let mut s: String = String::new(); /// "hello".clone_into(&mut s); /// /// let mut v: Vec<i32> = Vec::new(); /// [1, 2][..].clone_into(&mut v); /// ``` <del> #[unstable(feature = "toowned_clone_into", reason = "recently added", issue = "41263")] </del> <ins> #[stable(feature = "toowned_clone_into", since = "1.63.0")] </ins> fn clone_into(&self, target: &mut Self::Owned) { *target = self.to_owned(); }

#![feature(map_try_insert)] #![feature(new_uninit)] #![feature(thin_box)] <del> #![feature(toowned_clone_into)] </del> #![feature(try_reserve_kind)] #![feature(vec_into_raw_parts)] //