-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharing machinary with iterator-helpers toArray #23
Comments
Certainly it'd be ideal if they shared steps via abstract operations, but that'd likely happen after one of them had landed in the main spec. |
That sounds reasonable to me. |
For sharing this logic, this difference should be resolved tc39/proposal-iterator-helpers#168. At this moment, |
We will discuss this issue (as well as #19 and tc39/proposal-iterator-helpers#168) when we present this proposal for Stage 3 at the upcoming plenary meeting. We could try isolating the algorithm into its own abstract operation soon in anticipation of iterator-helpers. It’s just an editorial thing. Related: #1, #19, tc39/proposal-iterator-helpers#36, tc39/proposal-iterator-helpers#142, tc39/proposal-iterator-helpers#156. |
Hey, I was wondering, since
Array.fromAsync(iter)
is similar toAsyncIterator.from(iter).toArray()
wouldn't it make sense if they shared the same spec text? That is one (for example fromAsync) is defined and the other is defined in terms of it?(I agree that it makes sense to have both as it's more ergonomic and people will likely reach out to both - though that's not the discussion here)
The text was updated successfully, but these errors were encountered: