await enhancement proposal: Wrap Array return values with Promise.all

Michał Wadas michalwadas at gmail.com
Mon Sep 24 14:35:55 UTC 2018


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, <rosyatrandom at gmail.com>
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, <loganfsmyth at gmail.com> 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 <cilibrar at 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 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
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180924/e934045d/attachment-0001.html>


More information about the es-discuss mailing list