-
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
Annex B.3.5: Should we stop making for-of a special case? #1392
Comments
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. |
Made a concrete proposal in #1393. |
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 |
The relevant bug report and meeting notes also don't mention why |
@anba That sounds about right. I don't have anything written to point to, but my recollection was basically that since |
@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. |
Annex B.3.5, VariableStatements in Catch Blocks, says:
That is, we allow var-redeclaration of a non-destructured catch parameter...
...except in the particular case where the var declaration is a for-of initializer.
(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:
FIXME
(and a bug)The text was updated successfully, but these errors were encountered: