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

Annex B.3.5: Should we stop making for-of a special case? #1392

Closed
rkirsling opened this issue Jan 4, 2019 · 6 comments
Closed

Annex B.3.5: Should we stop making for-of a special case? #1392

rkirsling opened this issue Jan 4, 2019 · 6 comments
Labels
has consensus This has committee consensus. normative change Affects behavior required to correctly evaluate some ECMAScript source text question

Comments

@rkirsling
Copy link
Member

rkirsling commented Jan 4, 2019

Annex B.3.5, VariableStatements in Catch Blocks, says:

It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block unless CatchParameter is CatchParameter : BindingIdentifier and that element is only bound by a VariableStatement, the VariableDeclarationList of a for statement, the ForBinding of a for-in statement, or the BindingIdentifier of a for-in statement.

That is, we allow var-redeclaration of a non-destructured catch parameter...

try {} catch (e) { var e; }

...except in the particular case where the var declaration is a for-of initializer.

try {} catch (e) { for (var e of whatever) {} }

(Note that this behavior applies equally to sloppy and strict modes.)

Based on some earlier discussion I see in #150, it seems like the motivation here was to prohibit as much as possible without jeopardizing web compatibility. Still, if the for-of case is neither easy to remember nor trivial to implement, I wonder whether it provides concrete benefit to anyone. Should we simplify it away?


Current status in the major engines:

  • V8 and SpiderMonkey fully implement Annex B.3.5 and have special codepaths for the for-of case
  • JSC implements everything but the for-of case, for which it has a FIXME (and a bug)
  • ChakraCore allows any var-redeclaration of a catch parameter, destructured or otherwise
@ljharb
Copy link
Member

ljharb commented Jan 4, 2019

It seems exceedingly odd to me that:

function f(e) { for (var e of whatever) { } }

works but

try {} catch (e) { for (var e of whatever) {} }

errors.

@rkirsling
Copy link
Member Author

rkirsling commented Jan 4, 2019

Made a concrete proposal in #1393.

@littledan
Copy link
Member

This was pretty complicated to implement in V8, and came later than other parts of lexical scoping. Does anyone know the motivation? cc @allenwb @waldemarhorwat

@anba
Copy link
Contributor

anba commented Jan 21, 2019

The relevant bug report and meeting notes also don't mention why for-of was excluded. (Maybe only the web-compatibility necessary exclusion was considered to be necessary at the point in time?)

@syg
Copy link
Contributor

syg commented Jan 21, 2019

@anba That sounds about right. I don't have anything written to point to, but my recollection was basically that since for-of was a new feature, there was no reason to give it an extra allowance.

@ljharb ljharb added normative change Affects behavior required to correctly evaluate some ECMAScript source text question needs consensus This needs committee consensus before it can be eligible to be merged. labels Jan 29, 2019
@mathiasbynens mathiasbynens added has consensus This has committee consensus. and removed needs consensus This needs committee consensus before it can be eligible to be merged. labels Jan 29, 2019
ljharb pushed a commit to rkirsling/ecma262 that referenced this issue Feb 7, 2019
@allenwb
Copy link
Member

allenwb commented Feb 7, 2019

@syg Yes! That is correct. During ES6 development there was general consensus within TC39 that "undesirable" Annex B behaviors would not be added to new features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has consensus This has committee consensus. normative change Affects behavior required to correctly evaluate some ECMAScript source text question
Projects
None yet
Development

No branches or pull requests

7 participants