Repository navigation
&mut [MaybeUninit<T>]: Fill with value or with closure. #156
Description
Proposal
Problem statement
This feature would provide more options for making use of slices of uninitialized memory without dropping to unsafe by initializing MaybeUninit slices with closures or a repeated values, akin to slice::fill and slice::fill_with.
Motivation, use-cases
Uninitialized memory is a unique case in terms of read/write safety- it's the only case I can think of where it is safe to write to that memory but unsafe to read from it. In particular, it is safe to treat uninitialized memory as initialized once it has been initialized exhaustively. After calling any method which is guaranteed to initialize all indicies of a MaybeUninit, it is safe to assume_init on that slice.
Over the past couple of years, safe apis for doing MaybeUninit -> T such as write, write_slice, and write_slice_cloned have been introduced. write_slice corresponds to slice::copy_from_slice, while write_slice_cloned corresponds to slice::clone_from_slice. Both are guaranteed to initialize all elements of the slice.
However, there are a couple of other methods which give the same all-initialized guarantee, but there is no corresponding [MaybeUninit] api that safely returns an initialized slice: slice::fill and slice::fill_with.
Another argument for this besides simple write-only slice method API compliance is that, unlike with write_slice/write_slice_cloned, one doesn't need to safely write to initialized memory just so they can safely initialize the uninit memory. The memory can have values or closure results written directly to it without just having to hope LLVM can figure out that the safe write was unnecessary.
Solution sketches
I propose this API:
pub fn write_fill<'a>(this: &'a mut [MaybeUninit<T>], value: T) -> &'a mut [T]
where
T: Clone
Pretty much the equivalent to slice::fill, but it returns a slice of T at the end.
pub fn write_fill_with<'a, F>(this: &'a mut [MaybeUninit<T>], f: F) -> &'a mut [T]
where
F: FnMut() -> T
Like slice::fill_with.
Final Thoughts
RFCs suggest to mention potential drawbacks to your approach. One particular drawback that I can think of is MaybeUninit != Uninit, and the implication of this is that calling these methods on a partially initialized slice of MaybeUninit can cause destructors to leak. This is also true of the entire write API that already exists, and is debated on many issues (rust:80376, libs-team:122).
My opinion is that the solution to this is an Uninit api, which contains only the subset of MaybeUninit that guarantees that you either have truly uninitialized memory or you have to give up ownership of the Uninit in exchange for a T. Such an API would include the existing write api as well as these changes.
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
Activity
the8472 commentedon Dec 30, 2022
There's an RFC for in-place box initialization, I think that should take precedence. rust-lang/rfcs#2884
ajwock commentedon Dec 30, 2022
Oh yeah, that's pretty cool stuff.
I can eliminate the box portion from this ACP. Though I still would find it useful to be able to initialize MaybeUninit<T> slices with any of the same methods that I can exhaustively initialize slices of T with.
[-]&mut [MaybeUninit<T>] / Box<[MaybeUninit<T>]>: Fill with value or with closure.[/-][+]&mut [MaybeUninit<T>]: Fill with value or with closure.[/+]m-ou-se commentedon Oct 17, 2023
We discussed this in the libs-api meeting. This looks fine, without the
write_prefix.We think it'd also be useful to have a
fill_from(Iterator)function, which can terminate early, to only fill part of the available buffer (and then only return that part of the slice).Feel free to go ahead and add
fill,fill_withandfill_fromas unstable methods. Thanks!(Whether
fill_fromshould also be added to regular slices is a different discussion, that requires its own ACP.)programmerjake commentedon Oct 17, 2023
if
fill_fromis added on slices and also on slices ofMaybeUninitthey will probably conflict...I think this should be addressed somehow before approvingfill_fromm-ou-se commentedon Oct 17, 2023
@programmerjake The slice methods for MaybeUninit are added on
MaybeUninit, not on[MaybeUninit]. (See the signature above.)jmillikin commentedon Oct 28, 2023
@ajwock If you haven't already started work on the implementation for this, would it be OK with you if I did so? I could use this functionality for implementing another ACP, and the implementation seems straightforward.
Implement `MaybeUninit::fill{,_cloned,_mut,_with,_from}`
Implement `MaybeUninit::fill{,_with,_from}`
Implement `MaybeUninit::fill{,_cloned,_mut,_with,_from}`
jmillikin commentedon Oct 31, 2023
Tracking issue: rust-lang/rust#117428
Implementation PR: rust-lang/rust#117426 (note: API slightly adjusted)
ajwock commentedon Feb 17, 2024
@jmillikin Hey, for some reason github wasn't sending me emails about the updates here. Sorry I didn't see the messaging around this here. I have my original implementations laying around from when I made the proposal. If you're not pushing your implementation PR forward still, would you mind if I submit a PR with mine?
jmillikin commentedon Feb 18, 2024
@ajwock Feel free! I don't have the time or interest to push PRs past upstream resistance right now, so it's all yours.
You're also welcome to reuse any part of my PR in case that would be helpful to you.
Implement MaybeUninit::fill{,_with,_from}
Implement MaybeUninit::fill{,_with,_from}
Implement MaybeUninit::fill{,_with,_from}
Rollup merge of rust-lang#121280 - ajwock:maybeuninit_fill, r=Amanieu
Implement MaybeUninit::fill{,_with,_from}
Implement MaybeUninit::fill{,_with,_from}
Implement MaybeUninit::fill{,_with,_from}
Rollup merge of rust-lang#121280 - ajwock:maybeuninit_fill, r=Amanieu
Rollup merge of rust-lang#121280 - ajwock:maybeuninit_fill, r=Amanieu
Rollup merge of rust-lang#121280 - ajwock:maybeuninit_fill, r=Amanieu
Unrolled build for rust-lang#121280