Clarify statement regarding `windows_mut`

[Voultapher]

Location

https://doc.rust-lang.org/core/primitive.slice.html#method.windows

Summary

The documentation for slice::windows states:

There’s no windows_mut, as that existing would let safe code violate the “only one &mut at a time to the same thing” rule.

Either I don't understand how it would violate the unique reference rules of Rust or that statement is false. Using GATs it's possible to implement a version of windows_mut today as shown here, however that version is limited to slice windows of size known at compile time. But that limitation doesn't change the fact that it is - at leas to my understanding - perfectly fine to have multiple unique references to slice elements as long as they are not pointing to the same element, which can't happen by definition in slice::window.

[QuineDot]

[it is] perfectly fine to have multiple unique references to slice elements as long as they are not pointing to the same element, which can't happen by definition in slice::window.

You seem to be confusing windows* with chunk* here.

For example

From the windows documentation:

The windows overlap.
[...]

Examples

let slice = ['l', 'o', 'r', 'e', 'm'];
let mut iter = slice.windows(3);
assert_eq!(iter.next().unwrap(), &['l', 'o', 'r']);
assert_eq!(iter.next().unwrap(), &['o', 'r', 'e']);

(Note how 'o' and 'r' are in both slices.)

((Chunks don't overlap and chunks_mut exists.))

---

Either I don't understand how it would violate the unique reference rules of Rust or that statement is false. Using GATs it's possible to implement a version of windows_mut today as shown here,

The Iterator trait has a non-associated type and thus cannot support lending iterators (e.g. you can always collect all the items). That's the context of the current documentation. It could be more explicit about that:

There’s no windows_mut as an analog of Windows that implements Iterator<Item = &mut [_]> would let safe code violate the “only one &mut at a time to the same thing” rule by returning overlapping &mut [_] slices.

(There is no lending iterator trait in std.)

[Voultapher]

The Iterator trait has a non-associated type and thus cannot support lending iterators (e.g. you can always collect all the items). That's the context of the current documentation. It could be more explicit about that:

I think that was the missing piece for me, each individual iteration is valid but only if it has a unique borrow per iteration, the original documentation piece only talks about windows_mut, the implication that the returned value would have to implement the Iterator trait is not stated.

Can we find a wording of that phrase that makes the idea behind it more clear?

[hkBst]

The Iterator trait has a non-associated type

This is not correct. The Iterator trait does have an associated type, the difference with LendingIterator is that its associated type is not generic over any lifetime.