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

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

# Rudi Cilibrasi (6 years ago)

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 ,

Rudi Cilibrasi

# Logan Smyth (6 years ago)

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.

# Michael Luder-Rosefield (6 years ago)

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(/* */);
# Michał Wadas (6 years ago)

esdiscuss.org/topic/proposal