Does rust really need higher kinded types?

[shelby3]

@lambda

So, if by "leak a mutable reference", you mean that you can get mutable references during iteration, and save them somewhere else, then yes, you can do that:
...
So as you can see, you can indeed borrow in an iterator.

I should unpack my mental model that I implied upthread:

1. That when borrowing a mutable references, iterators do not enscapsulate resource lifetimes. An enumerable could leak resource lifetimes also if the callback function isn't pure (i.e. if it is a mutable reference). But they are not equivalent categories, because the iterator can be used in many more varied imperative coding scenarios where it can leak, so the compiler can't make a simple check on whether the callback function is pure because when using iterators there is no callback function (i.e. no constraint requiring functional programming) instead imperative spaghetti.

2. Afaik, your trait Iterator does not constrain the implementation from borrowing a mutable reference from the collection. There is nothing in the trait's signature for the consumer of the iterator to enforce at compile-time whether the iterator is leaking resources lifetimes other than to assume it is employing Rust's resource lifetime checking. For example, if we have an iterator instance and then we also add, delete, and rearrange the order of items in the collection, that iterator has to be updated by the collection, thus the collection has to allocate some resource such as storing a callback function.

@lambda

It turns out that in Rust, external iteration is a lot easier to make work with the borrow checker, works better with code that does things like early return from loops, and is more efficient and easier to optimize.

Well yeah why should it be surprising that an imperative spaghetti requires a low-level tsuris for resource lifetime checking.

Edit: Afaics, the functional programming alternative to the imperative spaghetti of iterators and so as to be able to implement all the algorithms @keean refers to from Essentials of Programming, is to have a separate trait for each such algorithm. While one might implement these traits with iterators, collections can also be optimized to implement some of them natively and with encapsulated resource lifetimes. So then @keean gets what he wants and I get what I want. Win win. And we then discourage most users from dealing with the low-level tsuris of iterators and resource lifetimes.