excluding features from sloppy mode
Mark S. Miller
erights at google.com
Wed Dec 26 20:00:44 PST 2012
On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich <brendan at mozilla.com> wrote:
> David Herman wrote:
>> On Dec 26, 2012, at 3:35 PM, Mark S. Miller<erights at google.com> wrote:
>>> I think you did coin "1JS". What do you mean by it? Does it bear on
>>> the present issue or not?
>> And it got shortened to 1JS not long after (maybe in the same thread?).
>> The key point was no (new) opt-in for ES6. If you read the message (see the
>> "Modules as the opt-in for new semantics" section), you'll see that I
>> actually proposed that anything that can't be made to work in legacy code
>> can be left out of sloppy mode.
> Not arguing in reply, rather taking this opportunity to expound/recollect a
> bit, bear with me!
> The lingering, not-quite-resolved issue I see Mark raising depends on the
> exact definition of "can be left out of sloppy mode" or (should that be
> reworded?) "can be included in sloppy mode but only with some
> incompatibility or contortion [but not binding-dependent parsing]".
> Long before 1JS, in prototyping ES4 features in SpiderMonkey "JS1.7" and up
> (which ended up in Rhino as well), and inspired by Opera's array
> destructuring, we started adding new features without requiring opt-in
> version selection. The new syntax was enough. This covered destructuring,
> and it turned off sloppy-mode craziness that was hard to implement or teach
> (e.g., destructuring parameters made duplicate formal parameters an error in
> JS1.7+, prefiguring strict mode).
> We ran into problems with 'let' and 'yield' used as identifiers, and lacking
> function* syntax for generators, we did require opt-in by version= for those
> two but nothing else.
> With 1JS as you proposed it (and if my memory serves), 'module' was enough
> to opt into new syntax (and it also implied "use strict"), but there was
> room for other new syntax outside of module (and outside of "use strict") to
> be its own opt-in.
> Since then I think TC39 has moved along toward enabling opt-in by new syntax
> where it's clean. New function head syntax (rest, default, destructuring
> parameters; function* for generators, which reserves yield in the body), at
> We knew 'let' could be a problem. Also we knew function-in-block was a
> breaking change. As you noted, and Brandon nicely separated in his reply as
> well, we can certainly require "use strict" to have function-in-block
> semantics. We may be left with no other choice.
> Just to recap the last TC39 meeting, we agreed to try reserving 'let' in
> sloppy mode. Mark wasn't happy about that, not so much because of
> incompatibility due to let[x] = y; changing meaning, more -- this is my
> interpretation, Mark should correct me -- because he wanted to promote
> strict mode, not elaborate sloppy mode ("don't polish a turd") , and keep
> each mode simpler by most measures.
You got it. I don't want to see the overall language become more
complex just so we can provide new features to sloppy mode.
I think the core of our disagreement is this:
Until ES3 browsers become insignificant, there is the additional
testing burden you mention. This is a transitional issue, but I agree
it is a significant one. But it will be years before ES6 rolls out in
browsers. Old browser versions fade out much faster than they used to
(due mainly to more aggressive auto update). So I do not expect
significant practical overlap between ES6 browsers and ES3 browsers.
Superstition aside, and once pre-ES5 browsers are not significant, the
only purpose of sloppy mode is for old code that must be kept running
without active maintenance. For any code being actively maintained, it
should move into strict mode. Sloppy mode will become a relic only for
code no one touches.
> I do not think the problems we anticipated with function-in-block and 'let'
> mean we retreat to requiring "use strict" for all new syntax outside of
> implciitly-strict modules. This is my punch-line: function-head new syntax
> in sloppy mode, including stricter error checking (e.g. for duplicate
> formals), should stand. It is better for the users, and probably even for
> the spec, to make such new syntax its own opt-in.
> So, case by case:
> * arrow function syntax (which does not imply "use strict" in body prologue)
> * class
> * const
> * default parameters
> * destructuring
> * rest parameters
> * generators (function*, yield in function* body)
> * comprehensions
> * generator expressions
> * module
> all seem to work in 1JS via the "new syntax is its own opt-in" rule,
> including any stricter/saner semantic checking.
> I left out 'let' and function-in-block. Let's set those aside for a moment.
> Anyone disagree that the bulleted syntactic extensions listed above should
> be their own opt-in, and think instead that some or others or all should
> appear only to strict code? (Mark, here's your chance! ;-)
I would apply one simple test to all of these: Does it make the
overall language simpler, and strict mode no more complex, to make
these available in sloppy mode as well? Most of these pass this test.
Once we started talking about micro-modes for new function syntaxes,
it became clear that these do not. So for these, if they cannot be
provided to sloppy mode without micro-modes, they shouldn't be
provided to sloppy mode at all.
More information about the es-discuss