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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 26 10:19:31 UTC 2016


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/8bf093a3/attachment-0001.html>


More information about the es-discuss mailing list