[rust-dev] iter library
niko at alum.mit.edu
Fri Apr 27 21:35:38 PDT 2012
On 4/27/12 8:02 PM, Joe Groff wrote:
> Is the wrapper type necessary? I thought named implementations were
> intended to allow multiple implementations without wrapping.
Sorry if I didn't make my purpose clear. The wrapper type is to
distinguish the different modes of iteration. For example, with maps,
do you want to iterate over the keys in the map, the values, or the
(key->value) pairs? Right now, we have separate methods for those
things (iter_keys, iter_values, etc), but that doesn't allow you to make
use of all the other associated iteration methods (foldl, map, etc).
You would need "foldl_keys", "foldl_values", and so forth. A similar
case occurs with strings (iterate by byte, by unicode character, by
word, by line, etc).
> Would the each() method of an iterator be resumable if you called it
> again after stopping a previous iteration? If so, you could implement
> a generic zip over any two iterators.
No, this is not currently possible. We don't support a cursor-based
API. This decision was made before I came around but I think it's a
good one. Cursor-based APIs are kind of a poor fit for the Rust memory
model, I think, which is very stack-oriented. Also, function-based APIs
are easier to compile efficiently and give you side benefits like making
it easy to determine when iteration has started and ended.
Still, a cursor-like iface or perhaps an iface for O(1) indexable types
might be useful additions in the future. They would enable more generic
> Could you implement a map<I,O,fn I -> O, iterable<I>> : iterable<O>
> adapter without higher kinds?
So, what is specifically not possible is use ifaces to write a generic
function that works on, say, any mappable collection. Of course we can
still define map() methods for any type and you can write methods that
operate generically using closures. It's not clear to me that the
current limits will be a problem in practice.
More information about the Rust-dev