On Tue, Jan 3, 2012 at 10:18 PM, Brendan Eich <bren...@mozilla.com> wrote:
> 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!).
>
"opt-in enough", interesting. I'm not sure if this is what you meant, but
it suggests a very attractive option I hadn't considered: treat "class",
like "module", as yet another way to opt-in to strict mode. All code
recursively inside a class would be strict.
>
>
> > 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. ;-)
>
For class, you're right. I really like the idea of having it be another way
to opt-in to strict mode. What other constructs might join "class" and
"module" as new strict-mode opt-ins?
>
>
> > 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?
>
Huh? In ES5, the following code is legal:
var let = 88;
The following code is not:
function foo() { "use strict"; var let = 88; }
I don't want to twist the grammar to turn "let" into a context sensitive
reserved word so that somehow
"var let = 88;" and use of let-scoping can co-exist in the same mode.
This seems like too high a price to pay simply to avoid any of the strict
mode opt ins. Any code under active maintenance should opt-in to strict
somehow anyway. Non-strict mode is only for legacy that needs to keep
working without any further human attention -- most of the web. This code
already doesn't use let scoping, so what's the issue?
>
>
> > 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.
>
Yes. In my initial email I said "For other ES6 features that do not depend
on these keywords, whether or not they must also be available in ES6
non-strict code we need to take on a case by case basis."
>
>
> > 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.
>
Again, the criteria I care about is "practically backwards compatible". If
it works to simply make "let" an unconditional keyword, then we should. On
this one, I'm skeptical. It is a short three letter english word. If there
are not many uses of it as a variable name, I would be very surprised. On
typeof, I am more than skeptical. I think this one is likely impossible
without a third mode. But if the data says otherwise, we should go with the
data.
But the "previously-illegal token sequence" approach complicates the
grammar and readability in ways that are not worth it, just to avoid any of
the means of opting in to strict, which all non-legacy code should do
anyway. For modules, we'd be taking the "previously-illegal token sequence"
approach in order to avoid introducing a third mode, which is so valuable
that the grammar and readability complexities are worth it.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
