ES6 doesn't need opt-in

Brendan Eich brendan at mozilla.com
Tue Jan 3 22:18:31 PST 2012


On Jan 3, 2012, at 9:52 PM, Mark S. Miller wrote:

> A good example. Since the class proposal uses  "private, public, static", by these principles, it would only be recognized in strict mode. If it appears in non-strict code, it would be a SyntaxError. 

That's a choice. I'm asking why it's the best one. Just because class syntax might involve new reserved identifiers doesn't require strict mode. The introductory keyword is class and the new keywords are all in the braced body.

The idea is that the always-reserved 'class' keyword is opt-in enough -- no need for a "use strict"; string litearl (ignored by old browsers anyway!).


> It would be, so long as that code is strict. Just say "use strict"; outside a module and you can use classes.

Why is this the best design, though? Why not just say 'class' followed by a head and body per whatever spec we agree on? (Assume we agree on one for some future edition. ;-)


> Want to use "let" scoping outside a module? Again, just say "use strict";.

The string literal directive is meaningless in old browsers, and the other new syntax than let is guaranteed to fail with a syntax error in old engines, so what's the benefit of requiring the extra "use strinct"; again?


> What remaining issues are there in using destructuring, spread, or rest in non-strict code? The short answer, not knowing what conflicts you have identified, is that if it is painless and backward-compatible (see below) to accept these in both strict and non-strict, then we should. Otherwise, we accept these only in strict code.

Ok, we should get into the particulars. It wasn't clear until this paragraph that any new features would be available in non-strict mode, in your view of the proposal. But in talking to Dave about it pre-launch I'm pretty sure we contemplated such a case-by-case "use new syntax to opt into ES6 from any mode" approach.


> I insert [practically] above to cover cases like completion reform. Although it is not formally backward compat, if it doesn't break any real programs besides test262 tests, we should go for it and arrange to forgive ES5 engines that implement it.

I agree on completion reform, but Oliver is game to try reserving 'let', and (typeof null == "null") still beckons. We can draw a more conservative line but IMHO it should not require "use strict"; to opt in if new syntax is unambiguous and starts with a reserved identifier or previously-illegal token sequence.

/be



More information about the es-discuss mailing list