On principle I do not want us to go down this path, even if we change later. It
adds risk that we won't change. It imposes a stateful model on iterators where
has_next and next must be coherent, and you have to write two methos (not one
as in Python or JS.next). And, Java.
/be
On Sep 28, 2011, at 3:27 PM, Patrick Walton wrote:
> It would be nice if we could figure out what to do about iterators for 0.1. I
> was thinking that we could make them Java-style iterators -- that is, objects
> with has_next() : bool and next() : T methods. |for each| would simply be
> syntactic sugar.
>
> This form:
>
> for each (x in iter()) {
> ...
> }
>
> Would desugar (in trans) into:
>
> let _i = iter();
> while (_i.has_next()) {
> let x = _i.next();
> ...
> }
>
> This has the following advantages:
>
> * Easy to implement.
> * Easy for LLVM to optimize. Simple SROA and inlining should make this as
> efficient as a for loop.
> * Simple performance model.
> * Familiar to programmers.
> * Allows us to support |break|, |cont|, and early |ret| easily.
> * Allows |break| and |ret| to be efficient. They simply throw away the
> iterator object. No special stack discipline necessary.
> * Makes upvars (outer variables referenced from the loop body) free in terms
> of performance.
> * Generator-like patterns can be achieved by making the iterator
> implementation use tasks internally.
> * Allows us to eliminate |put|.
>
> But it has these disadvantages:
>
> * Tasks can be more syntactically heavyweight than sequential-style iteration
> using |put|.
> * Data sharing between tasks is restrictive, which can make generator-like
> patterns awkward to use.
>
> Thoughts?
>
> Patrick
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
