On Wed, Jun 5, 2013 at 9:09 PM, Daniel Micay <danielmi...@gmail.com> wrote:
>
> All kinds of external iterators implement the following trait, whether
> they are
> a fibonacci number generator, a reverse iterator over a vector or iterator
> over
> a range in a sorted set:
>
> pub trait Iterator<A> {
> /// Advance the iterator and return the next value. Return `None`
> when the end is reached.
> fn next(&mut self) -> Option<A>;
> }
>
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.
> However, without support for compiling a function to a state machine (C#
> does
> this for yield), traversal of a recursive data structure has to be manually
> translated to a procedural algorithm with an explicit stack. For complex
> data
> structures, this process can be very difficult.
>
> I'm hopeful Rust will gain support for this down the road after 1.0. If it
> does, there will be no reason to write immutable internal iterators.
>
This could also be implemented with co-routines. Supposedly stack
switching will be separated from tasks sometime soon?
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
