ES6 opt-in, reloaded

Andreas Rossberg rossberg at
Tue Jan 17 04:49:27 PST 2012

On 16 January 2012 19:35, Brendan Eich <brendan at> wrote:
>> It's also worth noting that backporting
> That is a loaded verb-form ("backporting"). Who says there is a separate older spec or implementation to which to port?
> Yes, analyzing interactions requires reading the ES5 spec in non-strict mode. No, the result is not necessarily a port -- it's a patch (if you insist on hacking metaphors).
>> new ES6 features to classic
>> mode, as has been proposed by several people, clearly works against
>> (3),
> I object. 3 is misstated to assume "switching" means all-or-nothing. If ES6 has new features and they are worth using, developers will want to use them piecewise and conveniently. Assuming they will do so at the price of a leading "use version 6" or equivalent pragma is debatable. We shouldn't just assume this conclusion.

OK. But that sounds like a clear departure from the "
is based on strict mode" axiom that everybody seemed to have agreed on
long ago. Do we have consensus on abandoning that goal? (Thus my
description as "backporting".)

>> and consequently, also against (5/6).
> This does not follow. Users transitioning to use new features may be helped, not hindered, by we spec and implementation editors working harder. In particular allowing, e.g., destructuring in non-strict code may be boon to developers, whereas requiring them to maintain explicit opt-in pragmas before doing so simply to convenience spec editors and implementors may be a global loss.

Adding new features to both modes is almost guaranteed to lead to new
items to the list of non-strict vs. strict mode differences. That
implies new refactoring risks. I don't see a way around that.

>> Similarly, opting in at
>> smaller scope, as has also been discussed, is a blatant violation of
>> (6) and (7), and works against (3), too.
> Let's agree, based on your earlier arguments and also on Dave's point that lexical scope (free variable error analysis) won't work if opt-in is too local.

OK, I'm really glad. :)

>> So I have plea: let's keep it simple. Start from the simplest of all
>> possible ideas and optimize from there. That is, opting into ES6
>> through one simple declaration on the top of a program (and nowhere
>> else). Otherwise it's ES5 unchanged.
> You are arguing based on "simplest" without considering real-world usability. Too much a-priori system building makes a crashed sky castle, I've seen this over and over. On the web, a-posteriori wins.
> On the web, people lose version opt-in pragmas and MIME type versions (Larry Masinter made this point about the latter but it applies to the former). On the web, we have "use strict"; in the middle of concatenations. We have Unicode BOMs in the middle.

So you are saying that there still will be a refactoring hazard.
Agreed, but it is tiny compared to the other proposals.

> Meanwhile, JS1 grew via ES1-5 and various implementations (SpiderMonkey and Rhino) without any such opt-in, *except* for two keywords we couldn't reserve (and some incompatible change attempts that failed, vs. goal 8 -- one example: I tried to make == and != strict in JS1.2 to get ES1 to switch, but that broke the web, wherefore === and !==).

Doesn't that kind of make my point? Breaking changes, even small, need
opt-in. Strict mode has quite a few of them. Programmers need to be
aware of these. I claim that hiding the opt-in locally behind some
rather unrelated language feature will not make anybody's life simpler
(even if perceived otherwise).

> If so, it would be enough to say that a module
> declaration as the _first_ statement in the program also opts in _all_
> of the program.
> Why first if (as Dave's proposal in its minimal form did) a later module cannot affect earlier non-strict top level semantics? Again there is no backward compatibility issue. Why, as spec writer or implementor, do you care whether it's
>   <script>
>     // non-strict top level code
>   </script>
>   <script>
>     module {...}
>   </script>
> or the concatenation?

As an implementer, I don't necessarily. But as a programmer, I want an
easy way to tell the meaning of a local piece of code I'm reading. If
the place to opt-in is the beginning of the script, that's the only
place I have to look. If not, I potentially have to parse all the
preceding program text.

>> And before somebody brings it up: I do not fear that this will share
>> the fate of strict mode, because there actually is plenty of incentive
>> for using ES6 (especially, if we do _not_ extend classic mode).
> Another assumption. There may be more carrots this time, but if the explicit opt-in requirement is too unusable in practice, then ES6 may bounce, or simply have slower adoption that we'd like, ceteris paribus (many variables here, hard to project -- let's avoid arguing based on our favored speculations).

Dave makes this argument, too. I don't know, I may be naive, but I
have a very hard time believing that anybody would seriously consider
missing out on all the ES6 goodies only because he doesn't like
writing one additional, mechanic declaration.

I agree, "use version 6;" looks awful. (Mentioning specific versions
seems like a suboptimal idea anyway.)  Dave suggested "use module;"
(albeit with a somewhat different meaning). Why not just "module;"?
Then the rule could be even simpler: the first token decides. :)


More information about the es-discuss mailing list