Re: await enhancement proposal: Wrap Array return values with Promise.all

[Michał Wadas]

https://esdiscuss.org/topic/proposal-await-p1-p2-equivalent-to-await-promise-all-p1-p2



On Mon, 24 Sep 2018, 16:21 Michael Luder-Rosefield, 
wrote:

> Would it be possible to extend `await` such that you could `await.all()`?
>
> If not, one minor thing that might help cut down the noise (if it works
> with native Promises without this-binding; I've done it with RSVP):
>
> ```
> const { all } = Promise;
>
> await all(/* */);
> ```
>
> On Sun, 23 Sep 2018, 02:53 Logan Smyth,  wrote:
>
>> Making `await` itself do this would be a breaking change, so that'd be
>> very unlikely. There was discussion around an `await*` similar to the
>> existing `yield*` for generators, but I think it was deemed unneeded
>> complexity since `Promise.all` was already pretty easy to use, especially
>> since it isn't 100% obvious from the usage of an array what should be done.
>> For instance `Promise.race` also works on an iterable value. I'm not really
>> involved with the process, so I can't say more though.
>>
>> On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi 
>> wrote:
>>
>>> Greetings,
>>>
>>> I have enjoyed using the `await` keyword tremendously in async code. One
>>> point I notice in using it is that it is ideal in terms of clarity and
>>> composability but limited in a sense to sequential composition. That is, I
>>> cannot easily use `await` (by itself) to do parallel calculations.
>>>
>>> A few times, I have myself hit a bug where I return (without thinking)
>>> an Array of Promise only to find that none will resolve using `await` on
>>> the Array. I noticed others have similar bugs. [1,2] I frequently wind up
>>> wrapping them in one of two ways: a) occasionally a for loop that awaits
>>> each in sequence, but b) more often a `Promise.all`. I think the current
>>> `await` syntax makes every kind of sequential composition quite simple to
>>> read, write, and maintain, but the fact that we have to introduce
>>> `Promise.all` for each case of parallel (overlapping) execution seems to be
>>> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
>>> maintenance. It occurs to me that for my cases, and indeed perhaps others,
>>> a useful rule would be that all `await` on `Array` behave as if the Array
>>> were wrapped in `Promise.all`.  Then we can have a nice parallel
>>> composition syntax built into the language with the keyword using Array and
>>> lists can become idiomatic and concise parallel composition operators. I
>>> feel like this could improve the readability, power, and real time
>>> responsiveness of the language without necessarily sacrificing quality nor
>>> clarity.
>>>
>>> await on an Array value v acts as await Promise.all(v)
>>>
>>> Weighing against this idea seems to be the usual: operator tricks are
>>> unsearchable via keywords compared to `Promise.all`. So there is a style
>>> question however with the latest addition of the great new
>>> optional-chaining and pipeline ideas I thought it might be a good time to
>>> give this idea a try.
>>>
>>> What does the group think about this await enhancement proposal?
>>>
>>> Best regards,
>>>
>>> Rudi Cilibrasi
>>>
>>> [1]:
>>> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
>>> [2]:
>>> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>>>
>>> --
>>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>>> Professional Practice 
>>> ___
>>> 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
>>
> ___
> 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

Re: await enhancement proposal: Wrap Array return values with Promise.all

[Michael Luder-Rosefield]

Would it be possible to extend `await` such that you could `await.all()`?

If not, one minor thing that might help cut down the noise (if it works
with native Promises without this-binding; I've done it with RSVP):

```
const { all } = Promise;

await all(/* */);
```

On Sun, 23 Sep 2018, 02:53 Logan Smyth,  wrote:

> Making `await` itself do this would be a breaking change, so that'd be
> very unlikely. There was discussion around an `await*` similar to the
> existing `yield*` for generators, but I think it was deemed unneeded
> complexity since `Promise.all` was already pretty easy to use, especially
> since it isn't 100% obvious from the usage of an array what should be done.
> For instance `Promise.race` also works on an iterable value. I'm not really
> involved with the process, so I can't say more though.
>
> On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi 
> wrote:
>
>> Greetings,
>>
>> I have enjoyed using the `await` keyword tremendously in async code. One
>> point I notice in using it is that it is ideal in terms of clarity and
>> composability but limited in a sense to sequential composition. That is, I
>> cannot easily use `await` (by itself) to do parallel calculations.
>>
>> A few times, I have myself hit a bug where I return (without thinking) an
>> Array of Promise only to find that none will resolve using `await` on the
>> Array. I noticed others have similar bugs. [1,2] I frequently wind up
>> wrapping them in one of two ways: a) occasionally a for loop that awaits
>> each in sequence, but b) more often a `Promise.all`. I think the current
>> `await` syntax makes every kind of sequential composition quite simple to
>> read, write, and maintain, but the fact that we have to introduce
>> `Promise.all` for each case of parallel (overlapping) execution seems to be
>> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
>> maintenance. It occurs to me that for my cases, and indeed perhaps others,
>> a useful rule would be that all `await` on `Array` behave as if the Array
>> were wrapped in `Promise.all`.  Then we can have a nice parallel
>> composition syntax built into the language with the keyword using Array and
>> lists can become idiomatic and concise parallel composition operators. I
>> feel like this could improve the readability, power, and real time
>> responsiveness of the language without necessarily sacrificing quality nor
>> clarity.
>>
>> await on an Array value v acts as await Promise.all(v)
>>
>> Weighing against this idea seems to be the usual: operator tricks are
>> unsearchable via keywords compared to `Promise.all`. So there is a style
>> question however with the latest addition of the great new
>> optional-chaining and pipeline ideas I thought it might be a good time to
>> give this idea a try.
>>
>> What does the group think about this await enhancement proposal?
>>
>> Best regards,
>>
>> Rudi Cilibrasi
>>
>> [1]:
>> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
>> [2]:
>> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>>
>> --
>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>> Professional Practice 
>> ___
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await enhancement proposal: Wrap Array return values with Promise.all

[Logan Smyth]

Making `await` itself do this would be a breaking change, so that'd be very
unlikely. There was discussion around an `await*` similar to the existing
`yield*` for generators, but I think it was deemed unneeded complexity
since `Promise.all` was already pretty easy to use, especially since it
isn't 100% obvious from the usage of an array what should be done. For
instance `Promise.race` also works on an iterable value. I'm not really
involved with the process, so I can't say more though.

On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi  wrote:

> Greetings,
>
> I have enjoyed using the `await` keyword tremendously in async code. One
> point I notice in using it is that it is ideal in terms of clarity and
> composability but limited in a sense to sequential composition. That is, I
> cannot easily use `await` (by itself) to do parallel calculations.
>
> A few times, I have myself hit a bug where I return (without thinking) an
> Array of Promise only to find that none will resolve using `await` on the
> Array. I noticed others have similar bugs. [1,2] I frequently wind up
> wrapping them in one of two ways: a) occasionally a for loop that awaits
> each in sequence, but b) more often a `Promise.all`. I think the current
> `await` syntax makes every kind of sequential composition quite simple to
> read, write, and maintain, but the fact that we have to introduce
> `Promise.all` for each case of parallel (overlapping) execution seems to be
> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
> maintenance. It occurs to me that for my cases, and indeed perhaps others,
> a useful rule would be that all `await` on `Array` behave as if the Array
> were wrapped in `Promise.all`.  Then we can have a nice parallel
> composition syntax built into the language with the keyword using Array and
> lists can become idiomatic and concise parallel composition operators. I
> feel like this could improve the readability, power, and real time
> responsiveness of the language without necessarily sacrificing quality nor
> clarity.
>
> await on an Array value v acts as await Promise.all(v)
>
> Weighing against this idea seems to be the usual: operator tricks are
> unsearchable via keywords compared to `Promise.all`. So there is a style
> question however with the latest addition of the great new
> optional-chaining and pipeline ideas I thought it might be a good time to
> give this idea a try.
>
> What does the group think about this await enhancement proposal?
>
> Best regards,
>
> Rudi Cilibrasi
>
> [1]:
> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
> [2]:
> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>
> --
> Happy to Code with Integrity : Software Engineering Code of Ethics and
> Professional Practice 
> ___
> 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

await enhancement proposal: Wrap Array return values with Promise.all

[Rudi Cilibrasi]

Greetings,

I have enjoyed using the `await` keyword tremendously in async code. One
point I notice in using it is that it is ideal in terms of clarity and
composability but limited in a sense to sequential composition. That is, I
cannot easily use `await` (by itself) to do parallel calculations.

A few times, I have myself hit a bug where I return (without thinking) an
Array of Promise only to find that none will resolve using `await` on the
Array. I noticed others have similar bugs. [1,2] I frequently wind up
wrapping them in one of two ways: a) occasionally a for loop that awaits
each in sequence, but b) more often a `Promise.all`. I think the current
`await` syntax makes every kind of sequential composition quite simple to
read, write, and maintain, but the fact that we have to introduce
`Promise.all` for each case of parallel (overlapping) execution seems to be
a common cause of bugs and a minor aesthetic issue to me as well as perhaps
maintenance. It occurs to me that for my cases, and indeed perhaps others,
a useful rule would be that all `await` on `Array` behave as if the Array
were wrapped in `Promise.all`.  Then we can have a nice parallel
composition syntax built into the language with the keyword using Array and
lists can become idiomatic and concise parallel composition operators. I
feel like this could improve the readability, power, and real time
responsiveness of the language without necessarily sacrificing quality nor
clarity.

await on an Array value v acts as await Promise.all(v)

Weighing against this idea seems to be the usual: operator tricks are
unsearchable via keywords compared to `Promise.all`. So there is a style
question however with the latest addition of the great new
optional-chaining and pipeline ideas I thought it might be a good time to
give this idea a try.

What does the group think about this await enhancement proposal?

Best regards,

Rudi Cilibrasi

[1]:
https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
[2]:
https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript

-- 
Happy to Code with Integrity : Software Engineering Code of Ethics and
Professional Practice 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss