Making `await` itself do this would be a breaking change, so that'd be very unlikely. There was discussion around an `await*` similar to the existing `yield*` for generators, but I think it was deemed unneeded complexity since `Promise.all` was already pretty easy to use, especially since it isn't 100% obvious from the usage of an array what should be done. For instance `Promise.race` also works on an iterable value. I'm not really involved with the process, so I can't say more though.
On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi <cilib...@gmail.com> wrote: > Greetings, > > I have enjoyed using the `await` keyword tremendously in async code. One > point I notice in using it is that it is ideal in terms of clarity and > composability but limited in a sense to sequential composition. That is, I > cannot easily use `await` (by itself) to do parallel calculations. > > A few times, I have myself hit a bug where I return (without thinking) an > Array of Promise only to find that none will resolve using `await` on the > Array. I noticed others have similar bugs. [1,2] I frequently wind up > wrapping them in one of two ways: a) occasionally a for loop that awaits > each in sequence, but b) more often a `Promise.all`. I think the current > `await` syntax makes every kind of sequential composition quite simple to > read, write, and maintain, but the fact that we have to introduce > `Promise.all` for each case of parallel (overlapping) execution seems to be > a common cause of bugs and a minor aesthetic issue to me as well as perhaps > maintenance. It occurs to me that for my cases, and indeed perhaps others, > a useful rule would be that all `await` on `Array` behave as if the Array > were wrapped in `Promise.all`. Then we can have a nice parallel > composition syntax built into the language with the keyword using Array and > lists can become idiomatic and concise parallel composition operators. I > feel like this could improve the readability, power, and real time > responsiveness of the language without necessarily sacrificing quality nor > clarity. > > await on an Array value v acts as await Promise.all(v) > > Weighing against this idea seems to be the usual: operator tricks are > unsearchable via keywords compared to `Promise.all`. So there is a style > question however with the latest addition of the great new > optional-chaining and pipeline ideas I thought it might be a good time to > give this idea a try. > > What does the group think about this await enhancement proposal? > > Best regards, > > Rudi Cilibrasi > > [1]: > https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map > [2]: > https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript > > -- > Happy to Code with Integrity : Software Engineering Code of Ethics and > Professional Practice <http://www.acm.org/about/about/se-code> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
