Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

Michał Wadas michalwadas at gmail.com
Wed Oct 26 10:48:07 UTC 2016


You avoid only few very limited cases of parallelism.

When you use Promise.all you are awaiting either on *all promises to
resolve or first rejection*, but in case of rejecton, other promises don't
get cancelled/reverted. That's pattern not present in synchronous code.
Awaiting on values is more similar to synchronous code.
Awaiting for all promises can be necessary, but in most use cases it's
better to start processing already available values as fast as possible.
Though I appreciate map/filter methods from Array.prototype.

And on topic - await* is probably syntax to go (though I would recommend
asynchronous iterators proposal).
And on the margin - it would be nice to have functional
map/filter/each/reduce on native promises (Bluebird have these and they are
awesome).

On Wed, Oct 26, 2016 at 12:19 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> avoiding parallelism? can you please elaborate a bit more what's the code
> smell, exactly?
>
> On Wed, Oct 26, 2016 at 10:49 AM, Michał Wadas <michalwadas at gmail.com>
> wrote:
>
>> Actually using Promise.all with async/await is usually code smell - you
>> probably should await on values.
>>
>>
>>
>> On Wed, Oct 26, 2016 at 10:40 AM, Damian Senn <damian.senn at gmail.com>
>> wrote:
>>
>>> I don't like the `await* []` syntax, it doesn't really tell me what it's
>>> doing.
>>> I could imagine something like `await.all []` or `await.race []`
>>> desugaring to `await Promise.all([])` and `await Promise.race([])`, this
>>> could also be expanded to whatever new functionality might be added in the
>>> future (assuming await.something could work).
>>>
>>> On Wed, Oct 26, 2016 at 10:37 AM kdex <kdex at kdex.de> wrote:
>>>
>>>> Personally, I wouldn't mind such an operator, as I feel that the use of
>>>> `Promise.all` clearly
>>>> outweighs all other `Promise` combinators, but this could be an
>>>> opinionated view.
>>>>
>>>> IIRC, that even was up for standards discussion at some point (being
>>>> called `await*` instead
>>>> of `await`). I'm not sure what ever happened to that.
>>>>
>>>> On Wednesday, October 26, 2016 1:27:28 AM CEST Olivier Lalonde wrote:
>>>> > Right it makes sense, should have thought about that! An `awaitAll`
>>>> (or
>>>> > other syntax) could be nice but it seems the general opinion is
>>>> against.
>>>> >
>>>> > On Wed, Oct 26, 2016 at 1:22 AM, kdex <kdex at kdex.de> wrote:
>>>> >
>>>> > > It's especially beneficial for designing APIs where you don't care
>>>> about if
>>>> > > users pass you a `Promise` or the actual data to work with.
>>>> > >
>>>> > > Imagine a scenario where you would like to remove a set of files:
>>>> > >
>>>> > > ```js
>>>> > > async function remove(filesArray) {
>>>> > >         const files = await filesArray;
>>>> > >         /* … work with `files` here …*/
>>>> > > }
>>>> > > ```
>>>> > >
>>>> > > In the scenario above, you could pass an array of files, or a
>>>> `Promise`
>>>> > > that resolves
>>>> > > to said array; the function accepts both.
>>>> > >
>>>> > > On Wednesday, October 26, 2016 1:03:37 AM CEST Olivier Lalonde
>>>> wrote:
>>>> > > > I didn't realize `await` could be used on non-`Promise`s, never
>>>> mind. I
>>>> > > > wonder why that is, seems strange. Maybe so that async functions
>>>> could be
>>>> > > > more easily swapped out with sync ones in code? I do think
>>>> `Promise.all`
>>>> > > > should deserve special treatment because it is so common, unlike
>>>> > > > Promise.race (who uses that seriously?) and future combinators.
>>>> But I'm
>>>> > > not
>>>> > > > sure it is worth introducing new syntax for.
>>>> > > >
>>>> > > > On Wed, Oct 26, 2016 at 12:33 AM, Jordan Harband <
>>>> ljharb at gmail.com>
>>>> > > wrote:
>>>> > > >
>>>> > > > > Your suggestion would preclude having a promise for an array
>>>> (exactly
>>>> > > what
>>>> > > > > `Promise.all` returns).
>>>> > > > >
>>>> > > > > If you want `await` syntax for `Promise.all`, you'd need
>>>> different
>>>> > > syntax
>>>> > > > > for it - and then, what about `Promise.race`? What about other
>>>> future
>>>> > > > > combinators?
>>>> > > > >
>>>> > > > > On Wed, Oct 26, 2016 at 12:25 AM, Olivier Lalonde <
>>>> olalonde at gmail.com>
>>>> > > > > wrote:
>>>> > > > >
>>>> > > > >> I don't think so, what do you mean?
>>>> > > > >>
>>>> > > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
>>>> > > > >> raul.mihaila at gmail.com> wrote:
>>>> > > > >>
>>>> > > > >>> Then Promise.resolve([p1, p2]) should be like
>>>> Promise.all([p1, p2]) ?
>>>> > > > >>>
>>>> > > > >>> _______________________________________________
>>>> > > > >>> es-discuss mailing list
>>>> > > > >>> es-discuss at mozilla.org
>>>> > > > >>> https://mail.mozilla.org/listinfo/es-discuss
>>>> > > > >>>
>>>> > > > >>>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> --
>>>> > > > >> - Oli
>>>> > > > >>
>>>> > > > >> Oli Lalonde
>>>> > > > >> http://www.syskall.com <-- connect with me!
>>>> > > > >>
>>>> > > > >> _______________________________________________
>>>> > > > >> es-discuss mailing list
>>>> > > > >> es-discuss at mozilla.org
>>>> > > > >> https://mail.mozilla.org/listinfo/es-discuss
>>>> > > > >>
>>>> > > > >>
>>>> > > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > >
>>>> > >
>>>> > > _______________________________________________
>>>> > > es-discuss mailing list
>>>> > > es-discuss at mozilla.org
>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161026/85cb1674/attachment-0001.html>


More information about the es-discuss mailing list