excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Wed Dec 26 17:54:57 PST 2012

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?
> I coined the "just one JavaScript" here:
>      https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
> 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 least.

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.

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! ;-)


More information about the es-discuss mailing list