...strike that, I misread the "but that still waits for the async
functions to complete" part. So what you're proposing is that
everything functions normally inside the curly braces, but execution
doesn't continue until all promises have resolved? So your example
would work essentially like this:
```javascript
const x = doSomethingAsync();
const y = doSomethingElseAsync();
await x, await y;
// all promises are resolved by now, but
// still need to use await to unbox the values
someFunction(await x, await y);
```
On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <mr.jacob.bl...@gmail.com> wrote:
>
> >Maybe if you drop the "await" in your example:
> >
> >```javascript
> >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:
>
> ```javascript
> const x = doSomethingAsync();
> myFunction(await x)
> ```
>
> >```javascript
> >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):
>
> ```javascript
> 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.be...@web.de> 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@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
