Repository navigation
Tracking Issue for maybe_uninit_write_slice #79995
Description
Feature gate: #![feature(maybe_uninit_write_slice)]
This is a tracking issue for MaybeUninit::copy_from_slice and MaybeUninit::clone_from_slice.
These methods are the equivalents of [T]::copy_from_slice and [T]::clone_from_slice for uninitialized slices.
Public API
impl<T> [MaybeUninit<T>] {
pub fn write_copy_of_slice(&mut self, src: &[T]) -> &mut [T]
where
T: Copy;
pub fn write_clone_of_slice(&mut self, src: &[T]) -> &mut [T]
where
T: Clone;
}Steps / History
- Implementation: MaybeUninit::copy/clone_from_slice #79607
- Make slice methods inherent: Add inherent versions of MaybeUninit methods for slices #129259
- Stabilization PR: Stabilize
maybe_uninit_write_slice#148048
Unresolved Questions
- Should the name be changed back to
copy/clone_from_slice?- Reasoning for the original name and Revamp unstable MaybeUninit APIs libs-team#122
- Changed to
copy_from_sliceandclone_from_slicein Rename MaybeUninit::write_slice #116385 - Changed again to
write_copy_of_sliceandwrite_clone_of_slicein Add inherent versions of MaybeUninit methods for slices #129259
- MaybeUninit::write_slice_cloned() makes it very easy to accidentally leak #80376
Activity
beepster4096 commentedon Dec 13, 2020
Thomasdezeeuw commentedon Jan 30, 2021
These functions are great additions to the
MaybeUninitAPI.But if may open the bikeshed, should be renamed to
copy_sliceandclone_sliceto more closely match what the functions are actually doing? The current names are a little confusing/misleading. For example let's look at a similarly named function:MaybeUninit::write, it takes ownership of the value it writes and moves the value into theMaybeUninit. Howeverwrite_sliceandwrite_slice_cloneddon't do this as they copy/clone, so I think the "write" terminology can be a bit misleading.SimonSapin commentedon Jun 1, 2021
This seems like a great reason to name these methods
MaybeUninit::copy_from_sliceandMaybeUninit::clone_from_sliceveber-alex commentedon Jan 28, 2022
is it possible to add this as methods on
impl<T> [MaybeUninit<T>]?s1ck commentedon Sep 9, 2022
@drmeepster what are the plans on getting this stabilized?
Noah-Kennedy commentedon Sep 9, 2022
I'm pretty interested in seeing this stabilized as well.
Kixunil commentedon Sep 12, 2022
I think it just needs an ACP and approval.
SUPERCILEX commentedon Oct 17, 2022
Regarding the naming, I also think they should be called
{copy,clone}_from_slicefor consistency and ease of finding. The original reasoning for their current name is to indicate that the cloned values will NOT be dropped. However, I'd argue most people don't even realize that value replacement causes the old values to be dropped (I know I didn't until I thought about it). If you think about it for a bit it's obvious, but I don't think people associate "clone_from_slice" with "old stuff dropped". Instead, I think the docs can be a bit louder about the fact that old data won't be dropped.Rename MaybeUninit::write_slice
bend-n commentedon Jan 22, 2024
Then why is the api so different?
Auto merge of rust-lang#116385 - kornelski:maybe-rename, r=Amanieu
23 remaining items
joshtriplett commentedon Oct 28, 2025
We discussed these in today's @rust-lang/libs-api meeting, and we were happy with the curent names, both for clarity and for consistency with other APIs.
rust-rfcbot commentedon Nov 1, 2025
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.
This will be merged soon.
Rollup merge of rust-lang#148048 - thaliaarchi:stabilize-maybeuninit-…
Rollup merge of rust-lang#148048 - thaliaarchi:stabilize-maybeuninit-…
Rollup merge of rust-lang#148048 - thaliaarchi:stabilize-maybeuninit-…
Rollup merge of rust-lang#148048 - thaliaarchi:stabilize-maybeuninit-…
Unrolled build for #148048
Rollup merge of rust-lang#148048 - thaliaarchi:stabilize-maybeuninit-…