Re: How about awaiting Arrays ?

Nice one, but at that point `const all = a => Promise.all(a)` seems a better option. I think the point here is that we all need that and repeating the pattern every single time feels like a very clunky experience. `await.all` looks like a win  On Sat, Mar 11, 2017 at 6:24 PM, Axel Rauschmayer

Re: How about awaiting Arrays ?

I like the following way of using `Promise.all()`: ```js const all = Promise.all.bind(Promise); const allTheThings = await all([pa, pb, pc]); ``` > On 3 Mar 2017, at 13:43, Andrea Giammarchi > wrote: > > Not the first time I accidentally type the following: > >

Re: How about awaiting Arrays ?

As someone who teaches JavaScript a lot, I believe that not explaining what promises are when teaching async/await is not possible, because await only works on *promises*. You need to at least understand that promises are "async values" to understand and use aysnc/await. What is abstracted away is

Re: How about awaiting Arrays ?

I'm going to toy with my strawman some, previously introduced here: https://github.com/tc39/proposal-observable/issues/141 In particular, I'm going to try to address some of these concerns in an updated proposal. My goal is to come up with something that unifies both Promises and Observables, and

Re: How about awaiting Arrays ?

glad this topic moved some interest, but I'd like to share my opinion about locking down to `Promise.all` only any possible solution, as example: > I don't believe .race to be common use case (especially when we consider it's edge case with empty array). As mentioned already, `fetch` API is a

Re: How about awaiting Arrays ?

Honestly Isiah my largest motivation for thinking this is worth solving boils down to the fact that async/await does a good job of hiding the promise and generator based implementation under it but this falls down so fast when adding Promise.all. I'm helping a new person learn JavaScript right

Re: How about awaiting Arrays ?

First, I'll start out with this: I tend to be very adverse to new syntax, but I'll draw exceptions for things that enable whole new ways of looking at and manipulating code, like async functions and decorators, or things that enable new functionality altogether, like `function.sent` or private

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 12:27 PM, Mark S. Miller wrote: > > > On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas > wrote: > >> Actually I would go with >> >> await ...expr; >> > > I have not liked any of the prior suggestions on this thread. But this one > is

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas wrote: > Actually I would go with > > await ...expr; > I have not liked any of the prior suggestions on this thread. But this one is interesting. It has no compatibility problems, it composes nicely, and it suggests its meaning

Re: How about awaiting Arrays ?

My mistake Array.from is not necessary because Promise.all accepts any iterable. Though I don't believe .race to be common use case (especially when we consider it's edge case with empty array). Hsving parity with spread and rest parameters seems consistent for me. On 3 Mar 2017 17:54, "T.J.

Re: How about awaiting Arrays ?

On Fri, 3 Mar 2017 at 16:51 Michał Wadas wrote: > Actually I would go with > > await ...expr; > I think `await.all` is clearer and more explicit, and await.race could be added too. Also: here's previous discussion that didn't go anywhere:

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 4:51 PM, Michał Wadas wrote: > Actually I would go with > > await ...expr; > > As sugar for: > > await Promise.all(Array.from(expr)) Which is great for `Promise.all`, but leaves us without `race` or things that may be added in future (like Andrea's

Re: How about awaiting Arrays ?

Actually I would go with await ...expr; As sugar for: await Promise.all(Array.from(expr)) On 3 Mar 2017 17:15, "T.J. Crowder" wrote: On Fri, Mar 3, 2017 at 3:28 PM, Matthew Robb wrote: > > I think this conversation needs to happen

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 3:28 PM, Matthew Robb wrote: > > I think this conversation needs to happen but I am not sure baking > it into Array facilities makes the most sense. > > In my experience with async/await I am very often needing Promise.all but > in some cases the

Re: How about awaiting Arrays ?

I think this conversation needs to happen but I am not sure baking it into Array facilities makes the most sense. In my experience with async/await I am very often needing Promise.all but in some cases the other forms of multi promise capabilities. What if we expanded the keyword `await.all

Re: How about awaiting Arrays ?

If this is what we gonna have `[].promiseAll` then I'd rather `Promise.all()` You made some fair point, I guess there's nothing to see here. Regards On Fri, Mar 3, 2017 at 2:12 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Fri, Mar 3, 2017 at 12:43 PM, Andrea Giammarchi

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 12:43 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Not the first time I accidentally type the following: > > ```js > const allTheThings = await [pa, pb, pc]; > ``` > > I am assuming that JS will implicitly realize that'd be a > `Promise.all([pa, pb, pc])`

How about awaiting Arrays ?

Not the first time I accidentally type the following: ```js const allTheThings = await [pa, pb, pc]; ``` I am assuming that JS will implicitly realize that'd be a `Promise.all([pa, pb, pc])` call but nope. Then I also realize it'd be cool to have other shortcuts too that play nice with arrays