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

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

On Mon, 24 Sep 2018, 16:21 Michael Luder-Rosefield, <rosyatrandom at>

> 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> 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>
>> 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]:
>>> [2]:
>>> --
>>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>>> Professional Practice <>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list