[…asyncIterator] sugar for Array.fromAsync?

[danielbayley]

What do we think about adding polyfills for iterator helpers—currently at stage 3 of the TC39 process—and their async equivalent, currently at stage 2?

[bbrk24]

I wouldn't be against it, but aren't polyfills generally outside the scope of Civet?

[edemaine]

I agree that it seems out of the scope, given that this proposal seems to be a standard-library feature instead of a language feature. (Let me know if I misread.) So it seems you that you can just include an existing JS polyfill, and it'll work great with Civet.

[danielbayley]

given that this proposal seems to be a standard-library feature instead of a language feature. So it seems you that you can just include an existing JS polyfill

Ah of course, makes sense. Do you happen to know of a good one?

I did wonder if Civet could possibly have some kind of [...asyncThing] sugar for Array.fromAsync…

[edemaine]

The best polyfill I've found is https://github.com/MadProbe/iterator-helpers-polyfill
It's a bit out-of-date in the async side (see issue 15), but hopefully good enough for your purposes...

I'm not sure we want to redefine [...asyncThing] (though I see Array.fromAsync is backward-compatible in the sense that it supports regular iterators), but perhaps new notation like [...*asyncThing] could trigger this? Ideally we could also support [a, ...*b, ...c, ...*d] via something like [a, ...Array.fromAsync(b), ...c, ...Array.fromAsync(d)] (unless we can think up a more efficient compilation).

[bbrk24]

Array::concat can handle multiple arguments, and is way faster than multiple spreads: JSBenchmark .concat is about 5x faster for me (Firefox on Windows). So, the compilation would be [a].concat(Array.fromAsync(b), c, Array.fromAsync(d)).