Tracking Issue for maybe_uninit_fill

[jmillikin]

Feature gate: #![feature(maybe_uninit_fill)]

This is a tracking issue for ACP rust-lang/libs-team#156

Public API

// core::mem

impl<T> MaybeUninit<T> {
    pub fn fill<'a>(this: &'a mut [MaybeUninit<T>], value: T) -> &'a mut [T]
    where
        T: Clone;

    pub fn fill_with<'a, F>(this: &'a mut [MaybeUninit<T>], mut f: F) -> &'a mut [T]
    where
        F: FnMut() -> T;

    pub fn fill_from<'a, I>(
        this: &'a mut [MaybeUninit<T>],
        it: I,
    ) -> (&'a mut [T], &'a mut [MaybeUninit<T>])
    where
        I: IntoIterator<Item = T>;
}

Steps / History

• Implementation: Implement MaybeUninit::fill{,_cloned,_mut,_with,_from} #117426, Implement MaybeUninit::fill{,_with,_from} #121280
• Make slice methods inherent: MaybeUninit inherent slice methods part 2 #135394
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Naming: these were originally named fill, fill_with, and fill_from to be consistent consistent with slice::{fill_with,fill_from}. Since changing to slice-inherent methods, these needed to be renamed to avoid conflict. Should we change to naming that keeps fill? Amanieu suggested fill_init at Add inherent versions of MaybeUninit methods for slices #129259 (comment).

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Why do the functions return a shared reference instead of a mutable reference?

[jmillikin]

Why do the functions return a shared reference instead of a mutable reference?

#80376

If a &mut [T] is returned for T: Clone, there's no indication to downstream code that writing values to that slice will cause them to leak.

Are there plans to add mutable variants for the functions then?

[jmillikin]

I'm not planning to implement a <T: Clone>(&mut [MaybeUninit<T>], T) -> &mut [T] function as part of this feature, though I think it would be fine for someone else to do so if they have a view on what the correct Drop semantics should be.

Alternatively, maybe a -> &mut [ManuallyDrop<T>] would work for your use case? That would be safe to add since it makes the special-ness clear.

My use-case would an API along the lines of fn make_box<T:?Sized>(filler:impl FnOnce(&mut MaybeUninit<T>)->&mut T,size:<T as Pointee>::Metadata)->Box<T>, except with some traits to work around the lack of unsized MaybeUninit and a stable Pointee trait yet.

[jmillikin]

@python-ast-person If I understand you correctly, then you'd use the proposed fill_cloned to implement in-place construction of a Box<[T]> like this (playground link):

// presumed to exist as part of unsized MaybeUninit
impl<T> MaybeUninit<T> {
    fn transpose_slice<'a>(this: &'a mut MaybeUninit<[T]>) -> &'a mut [MaybeUninit<T>] {
        unimplemented!()
    }
}

fn make_box<T: ?Sized>(
    size: <T as Pointee>::Metadata,
    filler: impl FnOnce(&mut MaybeUninit<T>) -> &mut T,
) -> Box<T> {
    unimplemented!()
}

fn main() {
    let boxed = make_box::<[String]>(10, |u: &mut MaybeUninit<[String]>| {
        let a = String::from("a");
        let transposed = MaybeUninit::transpose_slice(u);
        MaybeUninit::fill_cloned(transposed, &a);
        unsafe { MaybeUninit::slice_assume_init_mut(transposed) }
    });
    println!("boxed: {boxed:?}");
}

Having MaybeUninit::fill_cloned() return a &mut [T] would provide only slightly cleaner code (one less line).

If you want construction of Box<[T]> to be possible without any unsafe at all, then you might want a helper function that takes ownership of its input, which should be Drop-safe. This can't be part of MaybeUninit directly because Box isn't available in the core crate, but it should be straightforward to implement if you already have unsized MaybeUninit in your codebase.

// internally does fill_cloned + slice_assume_init_mut() as above
fn fill_box_cloned<T: Clone>(this: Box<MaybeUninit<[T]>>,  value: &T) -> Box<[T]>;

[ajwock]

Hey, a couple of opinions on the API here.

One, I suggest that fill_from returns -> (&'a mut [T], &'a mut [MaybeUninit]) where the second slice is the uninitialized remainder. This produces a more useful API while harmless to anyone who doesn't want that remainder- they can just throw it away.

Another thing: I disagree that having fill_cloned should return an immutable reference. The &mut [T] returned from fill_cloned will already cause the destructors to be leaked regardless of mutability, or regardless of whether new values are written into the mutable slice. I don't know of any other method in std which takes a mutable reference and returns an immutable reference to the safe object and, in my opinion, should only be used where necessary to prevent true safety issues.

A box version was in my original proposal. I removed it due to a suggestion referring to rust-lang/rfcs#2884. Perhaps these two things should coexist, however.

[ajwock]

jmillikin has allowed me to take over implementation: #121280

[ajwock]

rust-lang/libs-team#338

This idea is my response to the (legitimate) criticism of these APIs that they could lead to destructor leaks.

[cynecx]

It would've been nice to also have the "same" interface for boxed slices:

impl<T, A: Allocator> Box<[MaybeUninit<T>], A> {
    pub fn fill(boxed: Box<[MaybeUninit<T>], A>, value: T) -> Box<[T], A>
    where
        T: Clone;
    
    // EDIT: Not needed because it is covered by above.
    // pub fn fill_cloned(boxed: Box<[MaybeUninit<T>], A>, value: &T) -> Box<[T], A>
    // where
    //     T: Clone;

    pub fn fill_with<F>(boxed: Box<[MaybeUninit<T>], A>, f: F) -> Box<[T], A>
    where
        F: FnMut() -> T;

    pub fn fill_from<I>(boxed: Box<[MaybeUninit<T>], A>, iter: I) -> Box<[T], A>
    where
        I: Iterator<Item = T>;
}

Does this need a new ACP or would it be possible to also consider this under maybe_uninit_fill?