I am not sure I understand why the iterator returned would every be something other than a concrete type. You have to return some type right? Rust already has universal quantification for lifetime parameters, but perhaps I am overlooking something.
Regarding functor map, i don’t think this is a substitute for iterators, although Rust has a very limited definition of iterators, that does not seem to include bidirectional, indexed, random, bifurcating and all the other coordinate structures found in Stepanov’s “Elements of Programming”. Personally I think iterators are a much more important concept than a map (which is actually an algorithm that can be implemented using an iterator). The idea of iterators as the abstract algebra of containers comes from the analysing the access patters used in different algorithms and then grouping them. Iterators naturally form a hierarchy so a container only every needs to provide one, but that may implement several traits. Algorithms that operate on containers then use the traits.
I have been implementing the Iterators from chapter 6 of “Elements of Programming” in Rust, although I am not completely happy yet the code is in GitHub if anyone it interested, as I think I have got to the point where I can see it is going to be possible to implement all the algorithms: https://github.com/keean/elements_in_rust
As for Rust features I would like:
- a way to generalise over move/reference passing
- introduction of write-only references (several write-only borrows can exist at the same time).
- separate read-only, and write-only dereference operators, in addition to full mutable deref which should only be usable on readable and writable references.
- traits to generalise all this (Readable, Writable and Mutable traits).
- a dereference operator that can dereference a non-reference value (is the identity function for non-references).
I don’t think any of those would count as popular requests, but the next one may be:
- negative trait bounds.