You might be drawing connections I didn't mean to make. Let's back up a minute.
- It's true that
.iter_mut()do not consume and do not yield
- It's also true that
.into_iter()is a method of a trait,
.iter_mut()are inherent methods.
- Finally, it's true that
.into_iter()is implemented on
.iter_mut()are implemented for
[T]and used on
But these three facts are essentially orthogonal; they have almost nothing to do with each other. You can't connect any of them with the word "because" or "therefore" because they all have different reasons.
- is just the definition of how iteration for those items works.
- is a consequence of the fact that there is no trait for
iter(). Partly this is because such a trait is inexpressible without GATs, as I mentioned earlier; however, you also don't really need a trait version of those methods because slices (and all well-behaved data structures) just make
foo.iter()an alias for
foo.iter_mut()an alias for
(&mut foo).into_iter(). There is no need for
IterableMuttraits to implement on
Vecbecause they would be redundant with the
IntoIteratorimplementations that already exist for
- is simply the consequence of two (unrelated) limitations in the Rust language itself. In the first place, it's not possible to implement
[T]without breaking backwards compatibility, although the limitation that originally prevented this from working has since been removed. But it's also not possible to call
self-taking methods on non-
Copyreceivers through a pointer unless the pointer is specifically
Box, because there's no
DerefMovetrait. This is another thing that has been proposed but no solid design for
DerefMovehas ever been established and it is less popular than GATs, so it probably won't be implemented any time soon.
My point is that there's not a grand unified theory that explains all these things, like you seem to be grasping for. All these facts are true but for different and mostly unrelated reasons. Don't look too hard for patterns or you'll start to see them where they aren't there.
As for other data structures that relate to each other like
Path. The thing to note about these is that none of the "borrowed" types are references; instead, they're the thing being referenced, because that's the only way you can implement
Deref. Your suggested system of
DataOnly<'_, T> would not be able to implement
Deref correctly (although I think you could do something with trait objects...)