-
Notifications
You must be signed in to change notification settings - Fork 33
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
Proposal to reconsider avoiding exposing of %AsyncFromSyncIteratorPrototype%
#190
Comments
I think this is more of a problem with WrapForValidAsyncIteratorPrototype, actually - it can directly return the value from the underlying iterator, like WrapForValidIteratorPrototype does, instead of creating and resolving a Promise. |
michaelficarra
added a commit
that referenced
this issue
Jul 7, 2022
michaelficarra
added a commit
that referenced
this issue
Jul 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to #182 (an extra wrapper for
%AsyncFromSyncIteratorPrototype%
)The previous discussion in #172
I agree that the previous approach is observable and will cause a problem for optimization. However, the new approach also will cause a problem with optimization.
I don't wanna analyze the spec completely, but
in my testing environment, before #182 runs microtasks 16 times, after - 24, I'm not sure about the correct number of ticks since some of them can be used for some other internal needs. However, this number makes me think about the need for such a change.
Removing extra ticks is a problem that now TC39 tries to solve - tc39/ecma262#2772 - and here we have such increasing.
Maybe makes sense to use another approach? For example, to make
%AsyncFromSyncIteratorPrototype%
exposing, but operations on it unobservable. How? For example, make.next
,.return
and.throw
on this object non-writable / non-configurable.The text was updated successfully, but these errors were encountered: