On 28/09/2011 3:27 PM, Patrick Walton wrote:
Thoughts?
- Tasks-as-generators style works regardless, is orthogonal.
- Inlining should work with closure-passing form as well, no?
the identity of the inlinees are all module-local constants
- Both models require "externalizing" (in a separate variable +
function call per iteration) some state while loop-optimizing
some other. Not clear to me there's any perf advantage, or a
substantial one.
- I prefer the closure-passing form:
- Already implemented, modulo possibly throwing out the "each"
keyword when we sink the range-loops into iters, and adding support
for break/cont/ret, but I'm ok deferring those anyways.
- We have no mechanism for "desugaring" at present and I don't really
want to make one up; but even if you do, you're giving magic-name
status to "has_next" and "next" rather than the magic-name "loopctl"
type we were discussing to make break/cont/ret work.
- Expresses the "iteratee is aliased during iteration" fact to the
alias-checker, so you don't have to worry about invalidating
externalized iterators. This is important; particularly if you want
to exploit next part ...
- Affords its own optimization opportunities, just elsewhere;
consider:
for (elt in vec::each(v)) { ... }
iter each<T>([T] v) -> T {
unsafe {
let p = ptr::addr_of(v[0]);
let e = p + vec::len(v);
while (p != e) {
put *p;
}
}
}
We can't do this with exterior iters.
I agree it should be mopped up before 0.1, but I prefer the path of just
finishing up loopctl and removing the 'for' / 'for each' distinction.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
