Hello, I cannot comment on the difficulty of implementation, however I can only join Armin in wishing that if it ever takes off it would be better to make the declaration explicit rather than having to parse the definition of the function to suddenly realize that this is not a simple function but a full-blown generator.
Furthermore, in keeping with the iterator ongoing, I would obviously push toward unifying the systems by having the generator implementing the Iterator trait (or whatever its name). -- Matthieu On Sun, Aug 11, 2013 at 12:01 PM, Armin Ronacher < [email protected]> wrote: > 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<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 > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
