[rust-dev] iter library

Niko Matsakis 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 
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


More information about the Rust-dev mailing list