[Feature request] Add [T]::windows_mut

[SimonSapin]

When borrows are involved, it is a common pattern to have a foo_mut variation of foo method. For example, [T] slices have a chunks method that takes &self and returns an iterator of &[T], and a chunks_mut method that is identical except that it takes &mut self and returns an iterator of &mut [T].

The windows method similarly takes &self and return an iterator of &[T]. However, the corresponding windows_mut does not exist, although it could sometimes be useful.

[alexcrichton]

I think that this would actually be unsound to implement. Each window is overlapping, and I believe that there's currently no guarantee that you can't do something like:

let mut parts = slice.windows_mut(4);
let part1 = parts.next().unwrap();
let part2 = parts.next().unwrap();
// part1/part2 overlap

I believe this is why iterators like IterMut fundamentally require unsafe code, but they're safe at an API level because the borrows they return are always disjoint (hence chunks_mut). I'm not 100% sure that this would be the case though, so I'd want to try it out first.

[SimonSapin]

Is it possible to write in a way that the result of next borrows the iterator (not just the slice) so that next can not be called again while the previous item still lives?

[alexcrichton]

I believe that due to the signature of Iterator, fn next(&mut self) -> Option<T>, there's no possibility to connect T to the lifetime of self.

[huonw]

(This is an example of something that could be tackled via "streaming iterators" e.g. https://github.com/emk/rust-streaming .)

[abonander]

@huonw is right but his link is broken 😄

[huonw]

Ah, github incorrectly included the trailing . in the autolinkification.

[steveklabnik]

Small API enhancements aren't tracked these days; we instead just accept PRs. Apparently this is blocked on streaming iterators, so a PR can't be sent in right now, but we still don't track random stuff like this. Closing!