-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Normative: Use GetMethod instead of GetV to get iterator next
#1288
Conversation
This is not "editorial" if it changes behavior of implementations. As such it would require testing against engines, test262 tests, and (assuming engines follow the current spec) sign-off on changing it. |
Okay. I'll fix the commit message, then. I misunderstood the distinction.
…On Thu, Aug 16, 2018, 11:17 Domenic Denicola ***@***.***> wrote:
This is not "editorial" if it changes behavior of implementations. As such
it would require testing against engines, test262 tests, and (assuming
engines follow the current spec) sign-off on changing it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1288 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AERrBB1MqC_lEn1nEcbSbCZhjUlcEkYNks5uRY0PgaJpZM4V_P48>
.
|
44ca605
to
2782dd7
Compare
next
next
@domenic Done. |
So Node/Chrome, Firefox, and Safari all have the same behavior. I haven't yet tested on Edge (don't have a VM ready), but it appears this would in fact be a theoretically breaking change. |
With a file of: [] = {[Symbol.iterator]: () => ({get next() { throw new Error("foo") }})};
[] = {[Symbol.iterator]: () => ({next: 0})}; I get these results: #### ch
#### v8
Error: foo
#### sm
Error: foo
#### jsc
Error: foo When I comment out the first line, no engines throw. |
@isiahmeadows the committee discussed this and had the following feedback:
|
@isiahmeadows are you still interested in pursuing this change? if so, the two points in #1288 (comment) need to be addressed - if not, this should be closed. |
@ljharb I do, but it's low priority. I'll close this for now, and I'll open a new issue and/or PR if/once I get the time to do it and address the feedback question. (I do also want to run it by V8 first to get their thoughts on it.) |
@isiahmeadows I'm going to close this per your previous comment. |
This is purely for consistency. Currently, only the first throws (tested in Node 10), but with this patch, the second would also throw:
In every other case, this has no effect since they all call IteratorNext before any other ECMAScript-visible behavior, and I feel this better aligns intuitively with what the spec implies.