r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rfcbot fcp merge

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

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 this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

I’ll leave my comment here instead of the tracking issue because this is where the FCP is.

Is one of our main goals for leak methods to be “better” versions of into_raw? If that’s the case maybe we should consider making this return a tuple with the capacity as well:

let (slice, cap) = vec.leak();

let vec = unsafe { Vec::from_raw_parts(slice.as_mut_ptr(), slice.len(), cap) };

so that you have all the info you need to reconstitute the Vec with from_raw_parts?

If we want to leave leak as is though, maybe we could consider another leak_parts as well.

@KodrAus The point of leak is that it is safe and allows you have a 'static slice that is valid for the entire lifetime of the program. You lose this if you return a raw pointer instead.

@Amanieu Right. I think my question is easily answered by an orthogonal leak_parts and leaving this method as-is is better 👍

We already have into_raw_parts #65816 for cases where the goal is to later use from_raw_parts

Yes, we’ve been talking on that thread about *mut T vs NonNull<T>. I had some more thoughts on how we can keep from_raw/into_raw methods consistent across container types while still letting you work with a NonNull. I’ll write it up. I just wanted to see if it was orthogonal to this method first, and it is.

I do think the docs for Vec::leak should note that excess capacity will be dropped.

Not dropped in the Drop sense, but not be accessible anymore yes.

The final comment period, with a disposition to merge, as per the review above, 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.

The RFC will be merged soon.

@bors r+

📌 Commit 7d759f5 has been approved by Amanieu

⌛ Testing commit 7d759f5 with merge 5ef872f...

☀️ Test successful - checks-actions, checks-azure
Approved by: Amanieu
Pushing 5ef872f to master...