Tracking Issue for maybe_uninit_write_slice

[beepster4096]

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 copy_from_slice<'a>(this: &'a mut [MaybeUninit<T>], src: &[T]) -> &'a mut [T]
    where
        T: Copy;

    pub fn clone_from_slice<'a>(this: &'a mut [MaybeUninit<T>], src: &[T]) -> &'a mut [T]
    where
        T: Clone;
}

Steps / History

• Implementation: MaybeUninit::copy/clone_from_slice #79607
• Stabilization PR

Unresolved Questions

• Should the name be changed back to copy/clone_from_slice? See reasoning for current name and Revamp unstable MaybeUninit APIs libs-team#122
  • Changed back in Rename MaybeUninit::write_slice #116385
• MaybeUninit::write_slice_cloned() makes it very easy to accidentally leak #80376

[Thomasdezeeuw]

These functions are great additions to the MaybeUninit API.

But if may open the bikeshed, should be renamed to copy_slice and clone_slice to 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 the MaybeUninit. However write_slice and write_slice_cloned don't do this as they copy/clone, so I think the "write" terminology can be a bit misleading.

[SimonSapin]

These methods are the equivalents of [T]::copy_from_slice and [T]::clone_from_slice for uninitialized slices.

This seems like a great reason to name these methods MaybeUninit::copy_from_slice and MaybeUninit::clone_from_slice

[veber-alex]

is it possible to add this as methods on impl<T> [MaybeUninit<T>] ?

[s1ck]

@drmeepster what are the plans on getting this stabilized?

[Noah-Kennedy]

I'm pretty interested in seeing this stabilized as well.

[Kixunil]

I think it just needs an ACP and approval.

[SUPERCILEX]

Regarding the naming, I also think they should be called {copy,clone}_from_slice for 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.

[bend-n]

These methods are the equivalents of [T]::copy_from_slice and [T]::clone_from_slice for uninitialized slices.

Then why is the api so different?

[kornelski]

It's not possible to implement these methods as inherent methods on impl<T> [MaybeUninit<T>], because such impl overlaps with impl<T> [T]. So either they have to have a different name, or they have to require a different syntax like MaybeUninit::copy_from_slice.

rust-lang/libs-team#122 suggested renaming to standard names, and there's a precedent for using "static" methods to avoid conflicts (e.g. Arc::as_ptr(&arc)), so they've now been moved to MaybeUninit::copy_from_slice/MaybeUninit::clone_from_slice.

@beepster4096 Could you update the issue description?