<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">AFAIK `await` can only accept an `expression` as a `Promise`, not other thing: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com">mr.jacob.bloom@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>why not just `await` as already is, but supporting an<br>
>iterable / array of promises, as `Promise.all` already does<br>
<br>
`await` can already accept a non-promise, so I believe that'd be<br>
breaking syntax if `Array.prototype.then` is set. It also requires<br>
collecting the promises in an array, which is what the proposed syntax<br>
is trying to avoid.<br>
<br>
On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">mr.jacob.bloom@gmail.com</a>> wrote:<br>
><br>
> >Just FYI, I previously suggested a couple things substantially more<br>
> >flexible than this<br>
><br>
> Ah, thank you for bringing those proposals to my attention. I looked<br>
> through the archives for relevant discussions but I must've missed<br>
> them.<br>
><br>
> It seems like we converged on a similar syntax for what you called<br>
> "merging," and the idea that there ought to be a separate syntax for<br>
> iteration. I don't know whether that means that this is the right<br>
> solution or just the most obvious one, but either way it's encouraging<br>
> to know that other people have the same difficulties with the current<br>
> syntax and are thinking about the problem.<br>
><br>
> >from my experience, committee members are in general<br>
> >very hesitant to add syntax for anything that doesn't pay for<br>
> >itself well<br>
><br>
> Yeah, I figured the bar would be high for new syntax. I've run into<br>
> the awkwardness of dealing with distinct parallel tasks several times,<br>
> and a few of the people I discussed it with were in the same boat, so<br>
> I wrote up this proposal thinking it might have a wide appeal. The<br>
> proposed syntax desugars via a relatively simple transformation but<br>
> encourages developers to reason about the problem in a completely<br>
> different way that I'd argue is more intuitive. Whether the committee<br>
> agrees and thinks it justifies a new syntax remains to be seen, but<br>
> either way I'm excited to see where this discussion goes (whether it<br>
> leads to the proposed syntax, to some other syntax, or to somewhere<br>
> else entirely).<br>
><br>
> As a side note: thank you to everyone for the thoughtful questions and<br>
> responses, I had no idea what to expect from this thread and it's gone<br>
> better than I could've hoped for. Thank you for not immediately<br>
> shooting down a proposal that looks similar to other proposals before<br>
> it.<br>
><br>
> On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a>> wrote:<br>
> ><br>
> > Just FYI, I previously suggested a couple things substantially more<br>
> > flexible than this [1] [2] (originated from this [3]), and it mostly<br>
> > fell flat due to being highly premature. Anything exclusive to<br>
> > promises is unlikely to win as library methods exist for basically all<br>
> > use cases and from my experience, committee members are in general<br>
> > very hesitant to add syntax for anything that doesn't pay for itself<br>
> > well. Similar questions have come up a few times in the past, too, and<br>
> > I've commented on two of them. [4] [5]<br>
> ><br>
> > If anything, I don't feel we know the problem space well enough, and<br>
> > the language lacks the primitives needed to really dig into it. (This<br>
> > is why I came up with my generator forking strawman. [6])<br>
> ><br>
> > [1]: <a href="https://github.com/isiahmeadows/non-linear-proposal" rel="noreferrer" target="_blank">https://github.com/isiahmeadows/non-linear-proposal</a><br>
> > [2]: <a href="https://github.com/isiahmeadows/lifted-pipeline-strawman" rel="noreferrer" target="_blank">https://github.com/isiahmeadows/lifted-pipeline-strawman</a><br>
> > [3]: <a href="https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal" rel="noreferrer" target="_blank">https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal</a><br>
> > [4]: <a href="https://esdiscuss.org/topic/stream-async-await" rel="noreferrer" target="_blank">https://esdiscuss.org/topic/stream-async-await</a><br>
> > [5]: <a href="https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing" rel="noreferrer" target="_blank">https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing</a><br>
> > [6]: <a href="https://github.com/isiahmeadows/proposal-generator-fork" rel="noreferrer" target="_blank">https://github.com/isiahmeadows/proposal-generator-fork</a><br>
> ><br>
> > -----<br>
> ><br>
> > Isiah Meadows<br>
> > <a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
> > <a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
> ><br>
> > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">mr.jacob.bloom@gmail.com</a>> wrote:<br>
> > ><br>
> > > ...strike that, I misread the "but that still waits for the async<br>
> > > functions to complete" part. So what you're proposing is that<br>
> > > everything functions normally inside the curly braces, but execution<br>
> > > doesn't continue until all promises have resolved? So your example<br>
> > > would work essentially like this:<br>
> > ><br>
> > > ```javascript<br>
> > > const x = doSomethingAsync();<br>
> > > const y = doSomethingElseAsync();<br>
> > > await x, await y;<br>
> > > // all promises are resolved by now, but<br>
> > > // still need to use await to unbox the values<br>
> > > someFunction(await x, await y);<br>
> > > ```<br>
> > ><br>
> > > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">mr.jacob.bloom@gmail.com</a>> wrote:<br>
> > > ><br>
> > > > >Maybe if you drop the "await" in your example:<br>
> > > > ><br>
> > > > >```javascript<br>
> > > > >await.all {<br>
> > > > >    const x = doSomethingAsync();<br>
> > > > >    //x is just the promise here<br>
> > > > >}<br>
> > > > >```<br>
> > > > ><br>
> > > > >...but that still waits for the async functions to complete, I think it would<br>
> > > > >cause fewer bugs and would seem to still satisfy the motivation?<br>
> > > ><br>
> > > > It doesn't seem like the `await.all` block is doing anything in that<br>
> > > > case. That code seems equivalent to this:<br>
> > > ><br>
> > > > ```javascript<br>
> > > > const x = doSomethingAsync();<br>
> > > > myFunction(await x)<br>
> > > > ```<br>
> > > ><br>
> > > > >```javascript<br>
> > > > >await.all {<br>
> > > > >  const x = await doSomethingAsync();<br>
> > > > >  //x is still undefined here!<br>
> > > > >}<br>
> > > > >```<br>
> > > ><br>
> > > > You bring up a good point about scoping and race conditions. It's a<br>
> > > > little tricky since the curly braces create a block scope but none of<br>
> > > > the parallel statements should be allowed to access each-other's<br>
> > > > variables, it's almost like each statement should have its own scope.<br>
> > > > Maybe it'd be better to have a syntax that ensures a set of curly<br>
> > > > braces for each parallel task? Async do-expressions could be a good<br>
> > > > solution (assuming they'd work kind of like an async IIFE):<br>
> > > ><br>
> > > > ```javascript<br>
> > > > async function initialize() {<br>
> > > >   let foo, bar, baz;<br>
> > > >   await Promise.all([<br>
> > > >     async do { foo = (await request('foo.json')).data },<br>
> > > >     async do { bar = (await request('bar.json')).data },<br>
> > > >     async do { baz = (await request('baz.json')).data },<br>
> > > >   ]);<br>
> > > >   render(foo, bar, baz);<br>
> > > > }<br>
> > > > ```<br>
> > > ><br>
> > > > (this is also a less drastic syntax change that piggybacks on an<br>
> > > > existing proposal)<br>
> > > ><br>
> > > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <<a href="mailto:a.d.bergi@web.de" target="_blank">a.d.bergi@web.de</a>> wrote:<br>
> > > > ><br>
> > > > > Hello!<br>
> > > > ><br>
> > > > > > This [current] structure is also just fundamentally different from working<br>
> > > > > > serially in async/await and it forces you to reason about the problem<br>
> > > > > > in a specific way. This doesn't appear to be a conscious decision to<br>
> > > > > > force good code practices<br>
> > > > ><br>
> > > > > Actually I'd argue that it is. Doing stuff concurrently *is*<br>
> > > > > fundamentally different from doing it serially, and should be reasoned<br>
> > > > > about every time you use it.<br>
> > > > ><br>
> > > > > kind regards,<br>
> > > > >  Bergi<br>
> > > > > _______________________________________________<br>
> > > > > es-discuss mailing list<br>
> > > > > <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> > > > > <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
> > > _______________________________________________<br>
> > > es-discuss mailing list<br>
> > > <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> > > <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>