Forwarding `return()` in generators

Brendan Eich brendan at mozilla.org
Thu Mar 26 11:18:53 UTC 2015


Axel Rauschmayer wrote:
> The way that `return()` is handled in generators (via try-catch) means 
> that the clean-up action is called in both cases: generator exhaustion 
> and generator closure. If you don’t use a generator then a clean-up 
> action in `return()` is only called if the iterator is closed, not if 
> it is exhausted. Obviously that is a minor technical detail and easy 
> to fix (call the clean-up action when you return `{ done: true }`), 
> but it’s still an inconsistency (which wouldn’t exist if `return()` 
> was called in either case).

We want `return` (Python 2.5+ close) to be optional, though. So an 
iterator whether implemented by a generator function or otherwise sees 
no difference -- provided in the generator function implementation you 
do not yield in a try with a finally. Forcing return from a 
not-exhausted generator parked at yield other than in try-with-finally 
does not run any more code in the generator function's body.

If you, the implementor of an iterator, want to handle close 
(pre-exhaustion break from a for-of construct), implement `return`. If 
you as implementor choose a generator function to implement your 
iterator, you'll want that try-finally.

In this sense, return for generator function, while provided as a method 
of generator iterators, is encoded in the body of the generator function 
at the implementor's discretion (via try-yield-finally -- arguably one 
big try-finally with the guts that use yield in the try block).

HTH,

/be


More information about the es-discuss mailing list