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
bi-directional communication seem to be similar to what Ruby does (as
described in the last section of my blog article).
I'll have to think more about implications of and use cases for this
kind of functionality. It would not be compatible with the current
std::Iterator trait though. And it may encourage writing hard-to-read
code/control flow. Though this is just a guess. Maybe its actually
easier to read and follow than the struct-with-methods equivalent.
I think Rust has an advantage over Python here, in that for every
function the return type is explicitly declared. So, if a function
returns an Iterator<T> (or better), one does not have to care about
whether the function is implemented via 'yield' or if it returns a
handwritten iterator.
You would think, neither do you in Python. The problem is actually
not so much the consuming of the function but the writing of it. In a
regular function you have execution as the function is called. In a
generator function the execution immediately suspends until you call
next(). It's very confusing for beginners and has caused in many,
many broken WSGI applications in Python (WSGI is the Python web
abstraction protocol that uses iterators).
Yes, it would certainly be more clear to not declare iterator fns as
regular functions (because they aren't :)
Though (IMO), it works rather well in C#. I don't have a strong opinion
on the subject.
Even more than that, how do you make an empty generator? [...]
I'd say, this should be a library function, something like
`Iterator<T>::empty()`.
With the `yield break` command from C# you could also have one canonical
version:
fn empty() -> Iterator<T> {
yield break;
}
Lastly, in Python 3 we now are getting async IO support through
generators and the frameworks do weird things to make generator and
regular functions decorated with the same decorator, behave similarly
in case someone deletes the last 'yield' from the function. An
explicit 'yield fn' outside of the function solves this case, where a
function degrades to not having any yield expressions any more.
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.
I think I know too little about this topic say something useful here.
But it seems like a specific library design issue.
-Michael
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
