why not just `await` as already is, but supporting an iterable / array of promises, as `Promise.all` already does, automatically discerning single promises vs multiple ones:
``` const promises = [...] // in parallel (`await` automatically acts as `Promise.all` here) const results = await promises results.forEach(result => ...) ``` On Thu, Nov 21, 2019 at 3:37 AM Isiah Meadows <[email protected]> wrote: > Just FYI, I previously suggested a couple things substantially more > flexible than this [1] [2] (originated from this [3]), and it mostly > fell flat due to being highly premature. Anything exclusive to > promises is unlikely to win as library methods exist for basically all > use cases and from my experience, committee members are in general > very hesitant to add syntax for anything that doesn't pay for itself > well. Similar questions have come up a few times in the past, too, and > I've commented on two of them. [4] [5] > > If anything, I don't feel we know the problem space well enough, and > the language lacks the primitives needed to really dig into it. (This > is why I came up with my generator forking strawman. [6]) > > [1]: https://github.com/isiahmeadows/non-linear-proposal > [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman > [3]: > https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal > [4]: https://esdiscuss.org/topic/stream-async-await > [5]: > https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing > [6]: https://github.com/isiahmeadows/proposal-generator-fork > > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[email protected]> > wrote: > > > > ...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 <[email protected]> > 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 <[email protected]> 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 > > > > [email protected] > > > > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
