search

DanielXMoore / Civet

A TypeScript superset that favors more types and less typing
https://civet.dev
MIT License
1.34k stars 28 forks source link

`[…asyncIterator]` sugar for `Array.fromAsync`? #1301

Open danielbayley opened 3 weeks ago

danielbayley commented 3 weeks ago

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 commented 3 weeks ago

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

edemaine commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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).