Tracking issue for slice::IterMut::as_slice and vec::Drain::as_slice

[cuviper]

This issue tracks stabilization for 2 methods added in #58924:

• core::slice::IterMut::as_slice
• alloc::vec::Drain::as_slice

[clarfonthey]

If this feature is accepted, they should implement AsRef as well.

[cuviper]

Good point, I didn't notice that slice::Iter already implements AsRef<[T]>. Another candidate that could is vec::IntoIter, and maybe there are more to consider for completeness.

[clarfonthey]

I actually didn't notice either until I went digging in for a totally separate issue. Will have a PR for that separately, although I won't include AsRef<[T]> for IterMut<'_, T> because it'd be instantly stable, and I'm not sure whether we want to guarantee that.

[talchas]

Is there a reason to not add as_slice_mut for these? Particularly IterMut, where it makes the iteration over mutable pairs nicer.

[clarfonthey]

@talchas Only into_slice_mut is sound, and that's offered at the moment. Otherwise, you can have multiple mutable borrows to the same spot in memory.

[talchas]

&mut self -> &mut [T] should be just as sound as &self -> &[T] here. It could not be &'a mut [T], but that's true for & as well.

[cuviper]

Yes, as long as it borrows from the IterMut itself, not its parameterized lifetime, as_slice_mut should be fine. I guess for mutable pairs, you mean something like this?

let mut iter = slice.iter_mut();
while let Some(x) = iter.next() {
    for y in iter.as_slice_mut() {
        // x and y are distinct `&mut T`
    }
}

[talchas]

Yeah, exactly that.

[CAD97]

What is the status of this? Is anything required for stabilization other than someone to propose stabilization, make a stabilization PR, and FCP?

In rowan, rust-analyzer's syntax tree backend, we're currently trying to remove unneeded allocations from syntax node cache hits. A simple patch that just does so via an arrayvec already sees a 5% improvement on rust-analyzer's main integration benchmark (not rowan's, and not purely parsing!), but being able to use the fact that vec::Drain already has a non-destructively-iterable array backing would make even that collect/copy unnecessary.

[m-ou-se]

One of thse (vec::Drain::as_slice) is already stabilized. As for the other one: we discussed this tracking issue in the libs meeting, and would be happy to see a stabilization PR.