Hi,
On 10/08/2013 14:23, Michael Woerister wrote:
Hi everyone,
I'm writing a series of blog posts about a possible *yield statement*
for Rust. I just published the article that warrants some discussion and
I'd really like to hear what you all think about the things therein:
http://michaelwoerister.github.io/2013/08/10/iterator-blocks-features.html
I have been toying around with the idea of yield for a bit, but I think
there are quite a few big problems that need figuring out.
The way "yield return" works in C# is that it rewrites the code into a
state machine behind the scenes. It essentially generates a helper
class that encapsulates all the state.
In Rust that's much harder to do due to the type system. Imagine you
are doing a yield from a generic hash map. The code that does the
rewriting would have to place the hash map itself on the helper struct
that holds the state. Which means that the person writing the generator
would have to put that into the return value.
I currently have a really hard time thinking about how the c# trick
would work :-(
Aside from this some random notes from Python:
- generators go in both directions in Python which caused problems
until Python 3.3 where "yield from" (your "yield ..") was introduced
that expands into a monstrosity that forwards generators into both
directions.
- instead of using "fn" like "def" in Python I would prefer if it was
an explicit "yield fn" that indicates that the function generates an
iterator. The fact that Python reuses "def" is a source of lots of
bugs and confusion.
Regards,
Armin
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
