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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Raul-Sebastian Mihăilă
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Olivier Lalonde
I don't think so, what do you mean?

On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Raul-Sebastian Mihăilă


On Wed, Oct 26, 2016 at 10:25 AM, Olivier Lalonde <[hidden email]> wrote:
I don't think so, what do you mean?

Conceptually, await is similar to Promise.resolve and this similarity is more useful than saving a few keystrokes.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jordan Harband
In reply to this post by Olivier Lalonde
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 <[hidden email]> wrote:
I don't think so, what do you mean?

On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Olivier Lalonde
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 <[hidden email]> 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 <[hidden email]> wrote:
I don't think so, what do you mean?

On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





--
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kdex
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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> >
> >> I don't think so, what do you mean?
> >>
> >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> >> [hidden email]> wrote:
> >>
> >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> [hidden email]
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>>
> >>
> >>
> >> --
> >> - Oli
> >>
> >> Oli Lalonde
> >> http://www.syskall.com <-- connect with me!
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Olivier Lalonde
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> >
> >> I don't think so, what do you mean?
> >>
> >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> >> [hidden email]> wrote:
> >>
> >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> [hidden email]
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>>
> >>
> >>
> >> --
> >> - Oli
> >>
> >> Oli Lalonde
> >> http://www.syskall.com <-- connect with me!
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kdex
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Damian Senn-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Michał Wadas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Michał Wadas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andrea Giammarchi-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

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

2016-10-26 13:14 GMT+02:00 Andrea Giammarchi <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > >> I don't think so, what do you mean?
> > > >>
> > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
> > > >>>
> > > >>> _______________________________________________
> > > >>> es-discuss mailing list
> > > >>> [hidden email]
> > > >>> https://mail.mozilla.org/listinfo/es-discuss
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> - Oli
> > > >>
> > > >> Oli Lalonde
> > > >> http://www.syskall.com <-- connect with me!
> > > >>
> > > >> _______________________________________________
> > > >> es-discuss mailing list
> > > >> [hidden email]
> > > >> https://mail.mozilla.org/listinfo/es-discuss
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss