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

Michael Luder-Rosefield rosyatrandom at gmail.com
Mon Sep 24 14:20:48 UTC 2018


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180924/e8b4aabb/attachment.html>


More information about the es-discuss mailing list