Add inherent versions of MaybeUninit methods for slices

[clarfonthey]

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

impl<T> MaybeUninit<T> {
    pub fn write(&mut self, value: T) -> &mut T;
    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;
}

Adding these APIs:

impl<T> [MaybeUninit<T>] {
    // 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.

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

The implementation looks pretty reasonable to me, but as this is an API decision:

r? libs-api

Is the intent here to replace the existing copy_from_slice and clone_from_slice? If so, those should be removed.

[clarfonthey]

I decided to not delete them since so many people are using these methods, but I can deprecate them depending on what people think is best.

[Amanieu]

We discussed this in the libs-api meeting. We're happy with these changes, but we would also like to see similar changes for the fill (#117428) and as_bytes (#93092) methods so that all slice-related methods are turned into inherent methods. Note that fill will need to be renamed since it conflicts with the generic fill method on slices (perhaps fill_init?).

Also, the old methods on MaybeUninit should be removed (in a separate PR) so that we don't have duplicate methods that do the same thing.

[tgross35]

Based on the above it seems like there are a few updates needed here.

@rustbot author

[tgross35]

Ah you know actually sorry, the change from fill* methods to write* is pretty significant (breaks consistency with slice) and should probably go back to libs-api.

Maybe it's easiest to move the fill changes to a separate PR so the rest of this can merge?

@bors r-

[clarfonthey]

Figured it makes more sense to pong this back to libs-api than mark it as my review, since libs-api did want to include these methods in the final PR.

r? libs-api
@rustbot ready

[tgross35]

@clarfonthey any chance you are willing to reconsider moving fill changes to another PR? I don't think there is any reason that change needs to happen at the same time.

Just asking because I'd like to start using this new API :)

[clarfonthey]

I mean, if you're cool merging this as-is without the fill methods, I'm fine splitting it. Just want to clarify which methods should be left in and which are left out.

[tgross35]

Specifically the changes fill -> write_filled, fill_with -> write_with, fill_from -> write_iter, since the names are the only things not okayed by someone from libs-api at #129259 (comment). So everything except those three are 👍 from me.

[clarfonthey]

Rebased and locally tested, but will wait for CI to pass before calling this officially ready. Moved the second half of the PR to #135394.

[clarfonthey]

Should be ready to merge!

[tgross35]

🎉

@bors r+

[bors]

📌 Commit e37daf0 has been approved by tgross35

It is now in the queue for this repository.