MaybeUninit inherent slice methods part 2

[clarfonthey]

These were moved out of #129259 since they require additional libs-api approval. Tracking issue: #117428.

New API surface:

impl<T> [MaybeUninit<T>] {
    // replacing fill; renamed to avoid conflict
    pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone;

    // replacing fill_with; renamed to avoid conflict
    pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T;

    // renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods
    pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>;
}

Relevant motivation for these methods; see #129259 for earlier methods' motiviations.

• I chose write_filled since filled is being used as an object here, whereas it's being used as an action in fill.
• I chose write_with instead of write_filled_with since it's shorter and still matches well.
• I chose write_iter because it feels completely different from the fill methods, and still has the intent clear.

In all of the methods, it felt appropriate to ensure that they contained write to clarify that they are effectively just special ways of doing MaybeUninit::write for each element of a slice.

Tracking issue: #117428

r? libs-api

[clarfonthey]

@rustbot blocked

[clarfonthey]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #135937) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

@rustbot label +I-libs-api-nominated

This PR renamed fill, fill_with and fill_from to write_filled, write_with, and write_iter and makes them inherent. Making these inherent was already approved but not the exact names. Some change has to happen because fill and fill_with conflict with [T]::fill{,_with}.

(Personally I prefer keeping fill and fill_with in the names to be consistent with slice, along the lines of Amanieu's fill_init suggestion at #129259 (comment).)

[RalfJung]

If we're picking new names anyway, can we also change the type of the closure and give them a usize argument so the initial value can depend on the index, a la https://doc.rust-lang.org/std/array/fn.from_fn.html ?

[RalfJung]

@clarfonthey please always include a reference to the tracking issue in the PR description for changes to an unstable API; otherwise it can become quite tricky to track the changes to a feature.

[clarfonthey]

Ah, you're totally right; these are all part of a single tracking issue that is now linked in the description.

[clarfonthey]

(Personally I prefer keeping fill and fill_with in the names to be consistent with slice, along the lines of Amanieu's fill_init suggestion at #129259 (comment).)

Also adding context that may be missed because the PR was split: copy_from_slice and clone_from_slice were renamed to write_copy_of_slice and write_clone_of_slice to add "write" in the name, so, unless renaming those is also desired, we would probably want to go with write_filled and write_filled_with instead of fill_init and fill_with_init.

In terms of fill_from, I especially prefer the name write_iter because, among other things, it actually might not full the entire slice if the iterator is too short. The result returned will be filled, but, it's not necessarily the length of the buffer, which could be confusing.

[Sky9x]

Please make sure these deprecated unstable methods do actually eventually get removed at some point (couple release cycles). The last time unstable methods were deprecated (pointer to_bits and from_bits), they were forgotten for 2 years (see #127071).

[Amanieu]

We discussed this in the libs-api meeting. We're mostly happy with the names for now, but this could be re-visited before stabilzation. Also we agree with @RalfJung's suggestion to add an index to the closure.

[clarfonthey]

Finally got around to this and made the requested change to add an index to the closure for write_with. Should be ready to review now.