&mut [MaybeUninit<T>]: Fill with value or with closure.

[ajwock]

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.

[the8472]

There's an RFC for in-place box initialization, I think that should take precedence. rust-lang/rfcs#2884

[ajwock]

There's an RFC for in-place box initialization, I think that should take precedence. rust-lang/rfcs#2884

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.

[m-ou-se]

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_with and fill_from as unstable methods. Thanks!

(Whether fill_from should also be added to regular slices is a different discussion, that requires its own ACP.)

[programmerjake]

if fill_from is added on slices and also on slices of MaybeUninit they will probably conflict...I think this should be addressed somehow before approving fill_from

[m-ou-se]

@programmerjake The slice methods for MaybeUninit are added on MaybeUninit, not on [MaybeUninit]. (See the signature above.)

[jmillikin]

@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.

[jmillikin]

Tracking issue: rust-lang/rust#117428

Implementation PR: rust-lang/rust#117426 (note: API slightly adjusted)

[ajwock]

@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]

@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.