Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

dead-claudia
Copy link

This is purely for consistency. Currently, only the first throws (tested in Node 10), but with this patch, the second would also throw:

[] = {[Symbol.iterator]: () => ({get next() { throw "foo" }})};
[] = {[Symbol.iterator]: () => ({next: 0})};

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.

@domenic
Copy link
Member

domenic commented Aug 16, 2018

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.

@dead-claudia
Copy link
Author

dead-claudia commented Aug 16, 2018 via email

@dead-claudia dead-claudia changed the title Editorial: Use GetMethod instead of GetV to get iterator next Normative: Use GetMethod instead of GetV to get iterator next Aug 16, 2018
@dead-claudia
Copy link
Author

@domenic Done.

@dead-claudia
Copy link
Author

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.

@ljharb ljharb added normative change Affects behavior required to correctly evaluate some ECMAScript source text needs consensus This needs committee consensus before it can be eligible to be merged. needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 labels Aug 16, 2018
@ljharb
Copy link
Member

ljharb commented Sep 25, 2018

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.

@ljharb
Copy link
Member

ljharb commented Sep 25, 2018

@isiahmeadows the committee discussed this and had the following feedback:

  1. It'd be great to see more of a motivating use case here for the normative change
  2. before merging a breaking change like this, we'd like to see at least one implementation of it (ie, one browser) both to signal web compatibility, and to indicate implementor buy-in.

@ljharb ljharb added the needs data This PR needs more information; such as web compatibility data, “web reality” (what all engines do)… label Sep 25, 2018
@ljharb
Copy link
Member

ljharb commented Jun 11, 2019

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

@dead-claudia
Copy link
Author

dead-claudia commented Jun 12, 2019

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

@bakkot
Copy link
Contributor

bakkot commented May 26, 2020

@isiahmeadows I'm going to close this per your previous comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs consensus This needs committee consensus before it can be eligible to be merged. needs data This PR needs more information; such as web compatibility data, “web reality” (what all engines do)… needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 normative change Affects behavior required to correctly evaluate some ECMAScript source text
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants