Hey Dave,
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:
`let` Identifier
or
`let` {
could have been valid ES5 syntax anyway. The situation for:
`let` [
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).
cheers,
G.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
