3 ms·

Rust is actually in the middle of changing how iteration (and eventually for-loops) works, from "internal iterators" as described in the article to even more fl

by rntz 13y ago

Rust is actually in the middle of changing how iteration (and eventually for-loops) works, from "internal iterators" as described in the article to even more flexible "external iterators". I'm not fully up-to-date, but this comment (http://lwn.net/Articles/557494/ http://lwn.net/Articles/557494/) on the original article links to a mailing-list post on the topic: http://thread.gmane.org/gmane.comp.lang.rust.devel/4528 http://thread.gmane.org/gmane.comp.lang.rust.devel/4528

saosebastiao 13y ago
Are internal iterators still possible?
- rntz 13y ago
  Internal iterators are just syntactic sugar for a higher-order function. As long as Rust has higher-order functions, internal iteration will be possible (just not "the standard way to do things"). Edit: In fact, this is true of any language with higher-order functions. For example, this is how you'd define a Rust-style internal iterator for lists in Racket scheme: (define (iter l f) (when (and (pair? l) (f (car l))) (iter (cdr l) f))) And how you'd use it: ;; displays elements of the list, up to and including the first one >= 3 (iter '(1 2 3 4) (lambda (x) (display x) (< x 3)))
  - kzrdude 13y ago
    but the `break`/`return` syntactic sugar inside for-loop closures will be lost.
    - rntz 13y ago
      Yes. You might be able to get something like it back with Rust's macro system, though. But it's probably better just to use the new syntax & iteration protocol, assuming the Rust folks come up with something reasonable.
    - kibwen 13y ago
      To be fair, it wasn't so much "syntactic sugar" as it was "a compiler hack that was rarely used and didn't even suffice for a large class of cases involving borrowed pointers".
      - dbaupp 13y ago
        And, it is an incorrect compiler hack (https://github.com/mozilla/rust/issues/6675 https://github.com/mozilla/rust/issues/6675), but that's not saying much at the moment.
- dbaupp 13y ago
  As kibwen explains above, Rust is just switching the dominant iteration protocol to external iterators, i.e. the protocol privileged/understood by the `for` syntactic sugar. It will still perfectly possible to write do tree.visit_each_leaf |leaf| { // ... do things with leaf ... if some_continuation_condition { true } else { false } } (The last line is the replacement for what would be currently written `if !some_continuation_condition { break }` with the `for` sugar.)

by rntz 13y ago

saosebastiao 13y ago

Are internal iterators still possible?

rntz 13y ago
Internal iterators are just syntactic sugar for a higher-order function. As long as Rust has higher-order functions, internal iteration will be possible (just not "the standard way to do things"). Edit: In fact, this is true of any language with higher-order functions. For example, this is how you'd define a Rust-style internal iterator for lists in Racket scheme: (define (iter l f) (when (and (pair? l) (f (car l))) (iter (cdr l) f))) And how you'd use it: ;; displays elements of the list, up to and including the first one >= 3 (iter '(1 2 3 4) (lambda (x) (display x) (< x 3)))
- kzrdude 13y ago
  but the `break`/`return` syntactic sugar inside for-loop closures will be lost.
  - rntz 13y ago
    Yes. You might be able to get something like it back with Rust's macro system, though. But it's probably better just to use the new syntax & iteration protocol, assuming the Rust folks come up with something reasonable.
  - kibwen 13y ago
    To be fair, it wasn't so much "syntactic sugar" as it was "a compiler hack that was rarely used and didn't even suffice for a large class of cases involving borrowed pointers".
    - dbaupp 13y ago
      And, it is an incorrect compiler hack (https://github.com/mozilla/rust/issues/6675 https://github.com/mozilla/rust/issues/6675), but that's not saying much at the moment.
dbaupp 13y ago
As kibwen explains above, Rust is just switching the dominant iteration protocol to external iterators, i.e. the protocol privileged/understood by the `for` syntactic sugar. It will still perfectly possible to write do tree.visit_each_leaf |leaf| { // ... do things with leaf ... if some_continuation_condition { true } else { false } } (The last line is the replacement for what would be currently written `if !some_continuation_condition { break }` with the `for` sugar.)