Add inherent versions of MaybeUninit methods for slices by clarfonthey · Pull Request #129259 · rust-lang/rust (original) (raw)

This is my attempt to un-stall #63569 and #79995, by creating methods that mirror the existing MaybeUninit API:

impl MaybeUninit { pub fn write(&mut self, value: T) -> &mut T; pub fn as_bytes(&self) -> &[MaybeUninit]; pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit]; pub unsafe fn assume_init_drop(&mut self); pub unsafe fn assume_init_ref(&self) -> &T; pub unsafe fn assume_init_mut(&mut self) -> &mut T; }

Adding these APIs:

impl [MaybeUninit] { // replacing copy_from_slice; renamed to avoid conflict pub fn write_copy_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Copy;

// replacing clone_from_slice; renamed to avoid conflict
pub fn write_clone_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Clone;

// identical to non-slice versions; no conflict
pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
pub unsafe fn assume_init_drop(&mut self);
pub unsafe fn assume_init_ref(&self) -> &[T];
pub unsafe fn assume_init_mut(&mut self) -> &mut [T];

}

Since the assume_init methods are identical to those on non-slices, they feel pretty natural. The main issue with the write methods is naming, as discussed in #79995 among other places. My rationale:

• The term "write" should be in them somewhere, to mirror the other API, and this pretty much automatically makes them not collide with any other inherent slice methods.
• I chose write_clone_of_slice and write_copy_of_slice since clone and copy are being used as objects here, whereas they're being used as actions in clone_from_slice and copy_from_slice.

The final "weird" thing I've done in this PR is remove a link to Vec<T> from assume_init_drop (both copies, since they're effectively copied docs), since there's no good way to link to Vec for something that can occur both on the page for std/primitive.slice.html and std/vec/struct.Vec.html, since the code here lives in libcore and can't use intra-doc-linking to mention Vec. (see: #121436)

The reason why this method shows up both on Vec<T> and [T] is because the [T] docs are automatically inlined on Vec<T>'s page, since it implements Deref. It's unfortunate that rustdoc doesn't have a way of dealing with this at the moment, but it is what it is, and it's a reasonable compromise for now.