https://esdiscuss.org/topic/proposal-await-p1-p2-equivalent-to-await-promise-all-p1-p2
On Mon, 24 Sep 2018, 16:21 Michael Luder-Rosefield, <[email protected]> wrote: > Would it be possible to extend `await` such that you could `await.all()`? > > If not, one minor thing that might help cut down the noise (if it works > with native Promises without this-binding; I've done it with RSVP): > > ``` > const { all } = Promise; > > await all(/* */); > ``` > > On Sun, 23 Sep 2018, 02:53 Logan Smyth, <[email protected]> wrote: > >> 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 <[email protected]> >> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
