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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 26 11:14:31 UTC 2016


> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161026/f4b05259/attachment-0001.html>


More information about the es-discuss mailing list