Proposal: `await.all {...}` for parallelism

Jacob Bloom mr.jacob.bloom at
Wed Nov 20 22:28:28 UTC 2019

>Maybe if you drop the "await" in your example:
>await.all {
>    const x = doSomethingAsync();
>    //x is just the promise here
>...but that still waits for the async functions to complete, I think it would
>cause fewer bugs and would seem to still satisfy the motivation?

It doesn't seem like the `await.all` block is doing anything in that
case. That code seems equivalent to this:

const x = doSomethingAsync();
myFunction(await x)

>await.all {
>  const x = await doSomethingAsync();
>  //x is still undefined here!

You bring up a good point about scoping and race conditions. It's a
little tricky since the curly braces create a block scope but none of
the parallel statements should be allowed to access each-other's
variables, it's almost like each statement should have its own scope.
Maybe it'd be better to have a syntax that ensures a set of curly
braces for each parallel task? Async do-expressions could be a good
solution (assuming they'd work kind of like an async IIFE):

async function initialize() {
  let foo, bar, baz;
  await Promise.all([
    async do { foo = (await request('foo.json')).data },
    async do { bar = (await request('bar.json')).data },
    async do { baz = (await request('baz.json')).data },
  render(foo, bar, baz);

(this is also a less drastic syntax change that piggybacks on an
existing proposal)

On Wed, Nov 20, 2019 at 11:50 AM Bergi <a.d.bergi at> wrote:
> Hello!
> > This [current] structure is also just fundamentally different from working
> > serially in async/await and it forces you to reason about the problem
> > in a specific way. This doesn't appear to be a conscious decision to
> > force good code practices
> Actually I'd argue that it is. Doing stuff concurrently *is*
> fundamentally different from doing it serially, and should be reasoned
> about every time you use it.
> kind regards,
>  Bergi
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list