<div dir="ltr">I don't like the idea of await behaving differently inside vs outside of the "await.all" block, and I think is a source of bugs:<div><br></div><div>await.all {</div><div>    const x = await doSomethingAsync();</div><div>    //x is still undefined here! Not the case outside of an await.all block</div><div>}</div><div><br></div><div>Maybe if you drop the "await" in your example:</div><div><br></div><div>await.all {</div><div>    const x = doSomethingAsync();</div><div>    //x is just the promise here, but at least is the same whether inside or outside of the await.all block</div><div>}</div><div><br></div><div>...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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Nov 2019 at 09:06, Cyril Auburtin <<a href="mailto:cyril.auburtin@gmail.com">cyril.auburtin@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"><div dir="ltr">There's `for await` loops since recently, there could be `await for` loops for wrapping the whole execution of a loop<div><br></div><div>```js</div><div>console.time(1);</div><div>await for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {</div><div>  console.timeLog(1, await fn());</div><div>}</div><div>console.timeEnd(1);</div><div>```</div><div><br></div><div>This would log the same than:</div><div><br></div><div>```js</div><div>console.time(1);<br>await Promise.all(<br>  [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]<br>    .map(async fn => { console.timeLog(1, await fn()) })<br>);<br></div><div>console.timeEnd(1);<br></div><div>/*</div><div>1: 51.066162109375ms a<br>1: 80.998291015625ms b<br>1: 81.315185546875ms<br></div><div>*/</div><div>```</div><div><br></div><div>without `await for`, things are serial:</div><div>```js</div><div><div>console.time(1);</div><div>for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {</div><div>  console.timeLog(1, await fn());</div><div>}</div><div>console.timeEnd(1);</div></div><div>/*</div><div>1: 50.68212890625ms a<br>1: 130.9951171875ms b<br>1: 131.1162109375ms<br></div><div>*/</div><div>```</div><div><br></div><div>(`var delay = t => new Promise(r => setTimeout(r, t));`)</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2019 at 6:44 AM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">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">Regarding parallel for-loops: I'd consider that a separate problem.<br>
You'd want parallel for-loops for things like requests to the same<br>
API, where each promise is handled the same way. `await.all` is more<br>
for handling disparate tasks in parallel without having to resort to<br>
thinking in terms of arrays and iteration.<br>
<br>
On Tue, Nov 19, 2019 at 10:27 PM Guy Bedford <<a href="mailto:guybedford@gmail.com" target="_blank">guybedford@gmail.com</a>> wrote:<br>
><br>
> Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel.<br>
><br>
> So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this.<br>
><br>
> Extending for loops to have a parallel form is another option (I seem to recall something similar brought up before here):<br>
><br>
> ```<br>
> for await.all (const entry of entries) {<br>
>   await doWork(entry);<br>
> }<br>
> ```<br>
><br>
> Whether async iteration should be supported or treated as sync or parallel is another question though, and possibly a confusion of the form.<br>
><br>
> On Tue, 19 Nov 2019 at 23:20, Jordan Harband <<a href="mailto:ljharb@gmail.com" target="_blank">ljharb@gmail.com</a>> wrote:<br>
>><br>
>> If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?<br>
>><br>
>> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">mr.jacob.bloom@gmail.com</a>> wrote:<br>
>>><br>
>>> To simplify the problem of working with promises in parallel, I<br>
>>> propose this new syntax:<br>
>>><br>
>>> ```javascript<br>
>>> async function initialize() {<br>
>>>   let foo, bar, baz;<br>
>>>   await.all {<br>
>>>     foo = (await request('foo.json')).data;<br>
>>>     bar = (await request('bar.json')).data;<br>
>>>     baz = (await request('baz.json')).data;<br>
>>>   }<br>
>>>   render(foo, bar, baz);<br>
>>> }<br>
>>> ```<br>
>>><br>
>>> Each child statement of the curly braces is evaluated in parallel and<br>
>>> execution resumes when they've all resolved.<br>
>>><br>
>>> **The Problem:** with current syntax, the above function would<br>
>>> probably look something like this:<br>
>>><br>
>>> ```javascript<br>
>>> async function initialize() {<br>
>>>   const [<br>
>>>     { data: foo }, // renaming response.data => foo<br>
>>>     { data: bar },<br>
>>>     { data: baz },<br>
>>>   ] = await Promise.all([<br>
>>>     request('foo.json'),<br>
>>>     request('bar.json'),<br>
>>>     request('baz.json'),<br>
>>>   ]);<br>
>>>   render(foo, bar, baz);<br>
>>> }<br>
>>> ```<br>
>>><br>
>>> For this kind of use case, `Promise.all` leads to "parallel lists" of<br>
>>> promises and their return values, which must be kept in sync. Using<br>
>>> those values either requires (sometimes deep) destructuring or<br>
>>> temporary variables.<br>
>>><br>
>>> This 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, it's just a limitation that falls naturally<br>
>>> out of the current syntax. Thus, we have an opportunity to shift some<br>
>>> of the burden back to the language with this new syntax.<br>
>>><br>
>>> Here's the full proposal:<br>
>>> <a href="https://github.com/mrjacobbloom/proposal-await-all" rel="noreferrer" target="_blank">https://github.com/mrjacobbloom/proposal-await-all</a> -- let me know what<br>
>>> you think!<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>
>> _______________________________________________<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>
_______________________________________________<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>