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

Behavior of for-in on null or undefined #377

Closed
GeorgNeis opened this issue Feb 10, 2016 · 2 comments
Closed

Behavior of for-in on null or undefined #377

GeorgNeis opened this issue Feb 10, 2016 · 2 comments
Labels

Comments

@GeorgNeis
Copy link
Contributor

What should happen when trying to enumerate (for-in) null or undefined? If I understand the spec correctly, currently such a for-in statement is equivalent to a break, which I find very strange:

http://tc39.github.io/ecma262/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind

6. If iterationKind is enumerate, then
  a. If exprValue.[[value]] is null or undefined, then
    i. Return Completion{[[type]]: break, [[value]]: empty, [[target]]: empty}.

(I would have expected that this returns a normal completion record with the undefined value.)

@bterlson
Copy link
Member

It does eventually return an undefined value with a normal completion. The break completion value is handled uniformly in 13.1.7. I'm not sure if the break semantics are required for some reason but it does just work with the existing machinery so that's a plus. You could imagine (I think) checking the result of evaluating the head in each block of 13.7.5.11, though I'm not inclined to change this without good reason.

@GeorgNeis
Copy link
Contributor Author

Thank you, I missed that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants