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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
