Rust's for-loop construct probably changed [LWN.net]

Rust's for-loop construct probably changed

Posted Jul 4, 2013 7:46 UTC (Thu) by renox (guest, #23785)
In reply to: Rust's for-loop construct probably changed by djc
Parent article: Philosophy and "for" loops — more from Go and Rust

Yes, Rust "pulled a Linus" and changed the semantic of their "for" loops just at the same time that the LWN article was up.
A very interesting comparison of internal(callback) vs external(cursor) iterators:
http://journal.stuffwithstuff.com/2013/01/13/iteration-in...

It's also discussed here http://www.reddit.com/r/programming/comments/1hl2qr/rust_...

Also I think that in the context of iterators D ranges should have been part of the LWN article..

to post comments

Rust's for-loop construct probably changed

Posted Jul 11, 2013 4:58 UTC (Thu) by eternaleye (guest, #67051) [Link] (1 responses)

Having read that article (and the sequel), there's one thing that bugs me a little about the tack Rust took. Rust *already* uses message-passing concurrency, and that allows a simple transformation from internal to external iterators by creating a stream, passing the chan into a task that runs the internal iterator (whose block closes over the chan), and then return or wrap an iterator for the port. So it startles me a bit that there isn't an Iterator implementation that does the transformation, yielding the best of both worlds.

Rust's for-loop construct probably changed

Posted Jul 11, 2013 23:35 UTC (Thu) by thestinger (guest, #91827) [Link]

You can currently use tasks to make an `Iterator` implementation, but context-switching for each iteration is too much overhead to be the iteration building block. C# has the ability to compile a generator to a state machine, and it's something Rust can implement in the future.