I'm happy to reserve 'yield' as a keyword for future experiments, but I
don't think we have either scope or a coherent enough design to commit
to doing anything particular with it at the moment. We're generally
trying to get all the things we have semi-working or agreed-to-be-done
*done* rather
On 12.08.2013 21:19, Graydon Hoare wrote:
I'm happy to reserve 'yield' as a keyword for future experiments, but I
don't think we have either scope or a coherent enough design to commit
to doing anything particular with it at the moment. We're generally
trying to get all the things we have
On 11.08.2013 15:25, Benjamin Striegel wrote:
Note that we have an issue open in the bug tracker for this:
https://github.com/mozilla/rust/issues/7746
Sorry for not replying to this earlier. Thanks for the hint! I have read
the discussion in the issue and tried to take it into account in my
On 13-08-12 02:42 PM, Michael Woerister wrote:
I know that the feature request (at:
https://github.com/mozilla/rust/issues/7746) is assigned to the far
future milestone. This thread and my blog series was intended to
collect information about the topic and get some light discussion about
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:
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
Note that we have an issue open in the bug tracker for this:
https://github.com/mozilla/rust/issues/7746
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 11.08.2013 12:01, Armin Ronacher wrote:
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
On 11.08.2013 12:31, Matthieu Monrocq wrote:
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
Hi,
On 11/08/2013 15:43, Michael Woerister wrote:
Maybe you do now :)
I see where this is going, that's actually not too bad. So essentially
it would generate some anonymous struct and impl.
Can you elaborate on what you mean by both directions?
Python has this inheritance tree (virtual):
Hi,
On 11/08/2013 16:18, Armin Ronacher wrote:
Yes, in theory you could make a function that returns nil but is
declared as returning an iterator, just return the empty iterator for
that type, but that seems wrong.
In addition to that does yield fn do a step towards solving the
confusion that
Hi,
[...] The reason I'm bringing this up is because in case Rust ever
wants to gain support for bidirectional generators it should from the
very start have something like a yield from to not break the reverse
forwarding.
Thanks for the extensive explanation. These iterators with
I wonder if Rust could do something along the lines of F# computation
expressions http://msdn.microsoft.com/en-us/library/dd233182.aspx (or
Haskell's do-notation, if one is so inclined). This approach would put
more strain on the optimizer, which would have to deal with all those
lambda
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:
14 matches
Mail list logo
