On Thu, Jun 6, 2013 at 6:19 PM, Vadim <[email protected]> wrote: > > Based on my experience with iterators in other languages, I would like throw > in the following idea: > > pub trait BlockyIterator<A> { > /// Advance the iterator and return the next block of values. > Return empty vector when the end is reached > fn next(&mut self) -> &'self [A] > } > > Rationale: when concrete type of the iterator is known, the next() method > inlines nicely. However, when used polymorphically, every iterator > advancement turns into a function call. A lot of that overhead could be > shaved off, if iterators can return multiple values at a time. A "normal" > Iterator can then be implemented on top of this trait. > > This is especially applicable to types which already store elements in an > vector, most notably [T] itself.
As you've mentioned, the existing Iterator trait allows you to return data in blocks if you desire (Iterator<&[T]> or Iterator<~[T]>). Essentially only vectors and vector-based deques can return a slice, so it wouldn't really be a generic trait. > This could also be implemented with co-routines. Supposedly stack > switching will be separated from tasks sometime soon? Coroutines/generators are quite cool, but they're far from free if they're implemented with context switching between code and not with a state machine - a switch involves swapping the registers and wiping out a lot of the cache. The C# solution can be as efficient as the code written by hand since it just generates a struct and a stateful iteration function, which is right in line with Rust's system's programming niche. The hard part would be implementing it, and managing to keep the borrow/move checking errors comprehensible (all your locals essentially become fields). _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
