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

Cyril Auburtin cyril.auburtin at gmail.com
Wed Oct 26 20:03:23 UTC 2016


await* would be cool, even if it saves just 10 chars.

2016-10-26 13:14 GMT+02:00 Andrea Giammarchi <andrea.giammarchi at gmail.com>:

> > in case of rejecton, other promises don't get cancelled/reverted
>
> **yet**, since cancelable Promises is something already available in
> bluebird and it will eventually land on JS land too (it'd be about the
> time, `Promise.all` is indeed yet another use case for cancelability)
>
> So yeah, `Promise.all` is for optimistic use cases, but I wouldn't call it
> a code smell: it's just a pattern.
>
> ```js
> Promise.all([
>   waitHourOn12,
>   waitMinuteOn12,
>   waitSecondsOn12
> ]).then(dingDong12);
> ```
>
> Regards
>
>
> On Wed, Oct 26, 2016 at 11:48 AM, Michał Wadas <michalwadas at gmail.com>
> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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/ed494b27/attachment-0001.html>


More information about the es-discuss mailing list