ES6 doesn't need opt-in
barraclough at apple.com
Mon Jan 2 15:18:42 PST 2012
I'm definitely in favour of removing the opt-in (or at least commonly removing the need to opt-in), and support the goal of one JS. Since most of the new syntax only relies on reserved words and, as Brendon stated, yield is only valid in function* constructs, the only problem so far as new syntax is concerned would seem to be `let`? Given how fundamental `var` is to writing a program in JS, if we intend `let` to be the new `var` then it would be a huge loss if this was the one new piece of syntax that wasn't available to all code.
Other than an ASI issue, which we can fix with a no-LineTerminator-here (as for module), I think we can just treat `let` as a contextual keyword in classic code, and it should be completely backwards compatible? I don't believe any statement beginning with:
could have been valid ES5 syntax anyway. The situation for:
is a little more tricky, since this could be a property access expression, however looking at the rules for ArrayBindingPattern it seems that this must always either be empty, end with a comma, or end with a BindingRestElement? If so, I don't think there is any pattern that will parse as both an ArrayBindingPattern and an Expression.
(Am I reading ArrayBindingPattern correctly, and is this the intention? – the rules for ArrayBindingPattern is a little confusing, since it allows:
[ BindingElementList `,` Elision<opt> BindingRestElement<opt> ]
which appears to be a slightly verbose way of saying:
[ BindingElementList Elision BindingRestElement<opt> ]
and there is also similar language in BindingElementList).
One issue with allowing let statements in classic code is that classic code also allows with statements, both constructs make use of the LexicalEnviroment, and as I read it the current runtime semantics could give rise to some, um, interesting behaviour! - but I wouldn't see this as a major concern.
If all new syntax is backwards compatible and enabled in all code then it raises the question, how exactly would the language change inside of a module?
1) Would we implicitly enable ES5-strict mode inside modules?
2) Do we change the behaviour of typeof inside modules?
3) Do we change static scoping / access to the global object inside modules?
(Does this cover everything?)
It seems likely that there will be users of the language who will take existing ES5 code, wrap it in module syntax, and expect this to work. If users do so, it seems to me that:
* It would seem most desirable for existing ES5 code were to just work.
* Next best would be if certain constructs were to generate an early error, making it impossible for a user to miss the compatibility issue.
* Less desirable would be for code moved into module to run without generating early errors, but to potentially be able to generate new runtime errors.
* Least desirable would be for code moved into a module to continue to function without throwing, but with subtly different runtime semantics.
> # But then what about static scoping?
> Compile-time checking of variables is a really important goal, and we don't have to abandon it. We just do the checking only within module code, relative to the current contents of the global object. This means it's still technically possible for globals to disappear at runtime (and consequently throw errors).
If I'm interpreting your proposal correctly then this would only result in new early errors, which I think makes this a very transparent and understandable change for developers – this seems like pure win.
The large majority of changes introduced by strict mode are new syntax errors, so implicitly enabling strict mode seems reasonable, but I have some concern about this – there are new runtime errors (albeit some would probably be covered by your stricter static scoping semantics), and there is the change in runtime behaviour for the handling of the this value.
Brendan's objection withstanding, I'm inclined to agree with you that we should not change the semantics of typeof.
So my answers to my three questions above would be a hesitant yes, no, and yes (per your static scoping proposal).
More information about the es-discuss