On 6/5/13 9:09 PM, Daniel Micay wrote:
I think extending the built-in `for` loop to work with external iterators
should be considered, because right now the verbosity discourages using them
and makes borrow checking more painful than it has to be.
It could treat functions as internal iterators, and look for an `Iterator`
implementation (using a `lang` item) for external ones.
Python's `for` loop starts by looking for an iterator (a `__next__` method) and
falls back to an iterable (an `__iter__` method) so behaviour like this isn't
an alien concept.
This is a very well-thought out post, and I find it persuasive. The
mutability issue is one I hadn't considered, and seems to make a good
argument for including both in the language.
There is also compilation speed to consider. I have not measured, but
intuitively I would guess that external iterators are faster to compile
than internal ones in codegen. This is because codegen has to create a
closure only to painstakingly break it apart again in optimization via a
combination of inlining, constant propagation, and scalar replacement of
aggregates.
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
