May be of interest to this discussion:
http://www.uop.edu.jo/download/PdfCourses/Cplus/iterators-must-go.pdf
Short presentation on the design of the std.range module in the D language,
which is intended to replace iterators.
-- Noel Grandin
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
