ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Sam Tobin-Hochstadt samth at ccs.neu.edu
Mon Apr 22 14:45:08 PDT 2013


What exactly would be the semantic difference between this and just using
'yield'?

Sam
On Apr 22, 2013 5:40 PM, "Domenic Denicola" <domenic at domenicdenicola.com>
wrote:

> From: Sam Tobin-Hochstadt [samth at ccs.neu.edu]
>
> > I don't see what the point of `await` is in your gist.  It looks like
> all of the work is being done by `function^`, which looks to be sugar for
> creating a function and passing it to a scheduler like `Q.async` or
> `taskjs.spawn`.  We could add that sugar if we wanted, and not need to add
> `await`.
>
> It's all a bit fuzzy in my head, I admit, but the idea is that `yield`
> should not have its meaning "taken over" by the promises-scheduler meaning.
> E.g. you could envision something that used both promises and generators,
> perhaps to yield a list of values retrieved asynchronously:
>
> ```js
> // ES6
>
> function* doubleSomeNumbers() {
>   return getNumbersToDouble().then(function* (numbers) {
>     for (var i = 0; i < numbers.length; ++i) {
>       yield numbers[i] * 2;
>     }
>   });
> }
>
>
> // ES-after-6:
>
> function*^ doubleSomeNumbers() {
>   const numbers = await getNumbersToDouble();
>
>   for (var i = 0; i < numbers.length; ++i) {
>     yield numbers[i] * 2;
>   }
> }
> ```
>
> This is obviously contrived, but I think illustrates how you might want to
> use both `yield` and `await` for their different meanings, instead of
> letting the wait-for-a-promise meaning take over `yield`.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130422/1b3d0fa7/attachment.html>


More information about the es-discuss mailing list