ES6 doesn't need opt-in

Andreas Rossberg rossberg at google.com
Wed Jan 4 04:23:56 PST 2012


Mark's reformulation of the proposal is somewhat different from how I
initially interpreted it -- in particular, wrt tying (merging)
extended mode to strict mode. But it seems like the logical
conclusion.

The main problem with the proposal (in both Dave's original form and
with Mark's refinement) is that it essentially gives up the idea that
Harmony builds on strict mode. It is not at all obvious to me what
implications that will have. A few observations:

- Despite the superficial "fewer modes" mantra, it actually doesn't
make the language simpler, but more complicated: instead of defining
the semantics for Harmony features only for strict-mode programs, we
now have to define many features for both modes (and mixed uses of
both modes). I.e., there are more syntactic and semantic combinations
to worry about.

- Providing Harmony features in classic mode decreases the incentive
for users to upgrade to strict mode. Is that a good thing?

- 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.

- All this together (new features in old mode, implicit opt-in,
explicit opt-in) makes it more subtle to see what piece of ES6 code is
strict and which isn't. This is a disadvantage when reading code and a
potential pitfall for refactoring (probably much worse than strict
mode today).

- Finally, not having a new mode restricts our ability to clean up the
language beyond what's already in strict mode (see typeof).

Considering all that, I can't help feeling that having a separate mode
is cleaner, simpler, and easier to use. I think it also has more
potential for providing a robust foundation for future evolution of
the language.

/Andreas


More information about the es-discuss mailing list