Proposal: Generator returning a value should throw SyntaxError

David Herman dherman at mozilla.com
Mon Jan 27 14:27:26 PST 2014


Here are several ways to think about return:

- A generator function is like a normal function but it can be paused. The act of pausing can send an intermediate value out to the caller (yield's argument) and the caller can send an intermediate value back in when resuming (yield's result). None of this changes the fact that, like ordinary functions, there are still arguments passed into the function and a result passed out. Refusing return values just breaks down this generalization.

- A generator function produces an iterator object, which produces a record on each iteration that has a .value and a .done flag indicating whether the iteration is done. Refusing return values eliminates the .value field in this special case, making things less consistent.

Finally, task.js is just an example of building a control abstraction out of iterators. It happens that the for-of control flow form is imperative and doesn't have a use for a return value. That doesn't mean other control flow operations won't.

Dave

On Jan 27, 2014, at 2:18 PM, Adam Ahmed <aahmed at atlassian.com> wrote:

> In light of the recent thread discussing async and await keywords, I thought it'd be appropriate to raise this point again, understanding it may be too late to make a change.
> 
> As my original post details, the concept of `return` within a generator is surprising in its difference in behavior from `yield`.
> 
> This does not do as 'expected' in a for-in:
> 
> function * threeCount() {
>   yield 1;
>   yield 2;
>   return 3;
> }
> 
> The argument for allowing return values was that usages in the vein of task.js will use the return value as a real return value and the yields for scheduling.
> 
> If we' re going to have async and await serve the scheduling purpose as well, can we remove the 'return' foot gun from generators? It sounds like it's just a stopgap until async-await, and a painful one, IMO. A syntax error on a generator that returns values would make the scheduling (async-await) vs iteration (generator) use cases much more clear. It'll be much easier for new JS devs to understand generators.
> 
> Happy to be shutdown again, just thought it was worth reconsidering with new async-await keywords in play.
> 
> On 27/09/2013 3:46 PM, "Brandon Benvie" <bbenvie at mozilla.com> wrote:
> On 9/26/2013 10:40 PM, Brandon Benvie wrote:
> ```js
> function* foo() {
>   yield 'what';
>   yield 'ever';
>   return "DONE";
> }
> 
> function* bar() {
>   console.log(yield* foo());
> }
> ```
> 
> Err, this logs "DONE" when you do:
> 
> ```js
> var gen = bar();
> gen.next();
> gen.next();
> gen.next();
> ```
> but you got the idea...
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list