How about awaiting Arrays ?
isiahmeadows at gmail.com
Sat Mar 4 02:11:52 UTC 2017
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
class fields. Things that haven't hit that bar for me include the bind
syntax proposal (beyond function pipelining) and the
`await.all`/`await.race` idea here.
BTW, I had some ideas on unifying that with observables at the syntax level
here, particularly with my `parallel` and `await parallel` ideas there:
Basically, it unifies the common case of merging promises and observables
with a fairly low syntactic footprint.
As for `Promise.race`, I see it much less frequently, and it's much simpler
and faster under the hood to implement due to less state needed, so I
didn't see the need to add support for that.
me at isiahmeadows.com
On Fri, Mar 3, 2017 at 11:59 AM, Michał Wadas <michalwadas at gmail.com> wrote:
> My mistake Array.from is not necessary because Promise.all accepts any
> 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. Crowder" <tj.crowder at farsightsoftware.com>
>> On Fri, Mar 3, 2017 at 4:51 PM, Michał Wadas <michalwadas at gmail.com>
>> > 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 `any`). (Granted `all` has to be
>> the dominant use case...)
>> Why the `Array.from` part of that?
>> -- T.J.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss