ES6 doesn't need opt-in

Andreas Rossberg rossberg at google.com
Wed Jan 4 09:24:29 PST 2012


On 4 January 2012 17:39, Mark S. Miller <erights at google.com> wrote:
> Here's an interesting compromise I consider perfectly reasonable. We don't
> *mandate* any ES6 code features be available in ES6 non-strict mode. But we
> don't prohibit them either. For any ES6 features that have no dependence on
> mode, like destructuring, we mandate that they be present in strict code,
> and we make them normative optional (the new Appendix B category) in
> non-strict code. Implementors are free to implement them or not in
> non-strict mode, but if they implement them, it must mean the same thing as
> the mandated meaning in strict code.

Hm, I don't understand what would be gained by that. You don't get rid
of the spec complexity. And you risk reducing cross-browser
compatibility, which is hardly a good thing. It doesn't really help
the browser vendors either.

I think for anything but legacy, we should avoid normative optional.

>> - After Dave's posting I foresaw people wanting implicit opt-in with
>> other constructs, e.g. classes or uses of `import' -- and voila, we're
>> already there. But even with that, you still have to rely on explicit
>> opt-in (via "use strict"?) for enabling some features elsewhere. As a
>> result, we expect programmers to remember two separate, fairly random
>> (for anybody not intimate with the history) lists of features that (1)
>> require opt-in, and (2) imply opt-in. Style guides will probably
>> suggest to put "use strict" on top of every Harmony program to escape
>> the mess.
>
> Every sane style guide will do so. And every linting tool should by default
> warn on the presence of any non-strict code. And every IDE should offer to
> make the code strict if it isn't already.

Well, I had hoped that with ES6 we have more elegant ways of opting
into Harmony than something like the "use strict" kludge. I also
thought that that was part of Dave's motivation.

/Andreas


More information about the es-discuss mailing list