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