On 9/28/11 9:17 PM, Graydon Hoare wrote:
- 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 ...
I don't understand this, sorry... could you explain?
- 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.
What about:
fn each<T>([T] v) -> fn()->option<T> {
let p, e;
unsafe {
p = @mutable ptr::addr_of(v[0]);
e = p + vec::len(v);
}
ret lambda() {
unsafe {
if p < e {
let rv = *p;
*p = ptr::next(*p);
ret some(rv);
}
ret none;
}
}
}
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.
The complexity of loopctl is what I'm worried about, I guess. It
requires a bunch of dynamic "did this loop break? did this loop
early-return?" checks. I'm not sure what the precedent for this is.
The thing that makes my proposal possibly problematic is that it ties
option::t into the language at a much closer level than it's ever been
tied before. I'm quite possibly ok with that, given that there are
optimization opportunities for option::t that pretty much no other tags
get (specifically, optimizing option::t<~T> and option::t<@T> into null
pointers instead of two words). But it does mean that it's probably a
post 0.1 feature.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
