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 combinators.
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.
Niko _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
