excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Mon Dec 31 19:49:45 PST 2012

Kevin Smith wrote:
>     And again, ES5 failed to reserve 'module' in strict mode, and
>     ES1-3 never reserved 'module', so ES6 must make 'module' only
>     contextually reserved. We are already in "either it's an
>     identifier, or it isn't" default. If we can do it for 'module',
>     why not for 'let'?
> Easy: "module" is still a first class identifier, but with your 
> proposed contortions, "let" is not (under sloppy mode, of course).

No, that's not correct. We have sloppy-mode code using 'let' as an 
identifier (whatever "first class" means) today. We don't want to break it.

The only place 'let' is contextually reserved in the quasi-consensus 
from the last TC39 meeting is at the start of a statement, when followed 
by an identifier, '{', or '['.

Similarly, 'module' is used and usable as an identifier, but not in 
malformed syntax that ES6 proposes to define: 'module' [no 
LineTerminator here] ModuleName ... at the start of a statement.

>         Personally, yes.  Only modules loaded by the module loader are
>         implicitly strict.
>     Now I'm confused. What about module M {...} (inline body)? What
>     does "the module loader" mean, the system loader?
> Inline modules only in strict mode, in accordance with the rule.  Only 
> out-of-line modules are implicitly strict.

Any use-case-based rationale?

Thanks for clarifying the primacy of "the rule". It was not clear, and 
it does not match what Dave proposed that Mark reconfirmed as "1JS". 
Although Dave left some wiggle room in his first post, I want to say 
that my attempts to make all new body-forms strict don't fit under the 
consensus "1JS" name and I'm not trying to usurp it. Your proposal 
should be called "2JS" since to get the new stuff, you have to "use strict".

> I will bet you real (beer) money you're wrong.
> Alright - I'll take you up on that.  If in 2022 anyone is using script 
> tags for anything more than bootstrapping a module loader, I'll buy 
> you a New Year's Eve beer!


>     * It's an eyesore, which I think is a non-trivial objection.
> Yes, but it's not required in out-of-line modules.  Which will 
> predominate quickly in new code (my prediction, yes).

I don't think so in the browser. Concatentors will be required to 
minimize requests, which will make modules inline again.

>     * It is easy to leave out and hard to find when checking whether
>     code in the middle of a function nest is strict.
> Yes, it is easy to leave out, at least until you want to use an ES6 
> feature.  Then you get spanked : )

Yeah, that's the thing I find turns off people at the "social BS" level. 
The Strunk&White-ian prescriptivism rings false and the kids start 
sassing off the gray-hairs. Not good for the Shire :-P.

> I'm going to stop there.
> Brendan, I feel like I'm in a compromising mood this evening.  I can't 
> really tell whether it's because your arguments have merit or because 
> of argument by sheer exhaustion (as a previous computational theory 
> professor of mine once said)...

We can wait till next year :-P and re-check. I'm not trying to bully 
anyone, just be a vigorous advocate (but not devil's advocate).

> In any case, here's my compromise:
> (1) No opt-in required for new syntax, except:
> (2) No breaking changes to sloppy mode, and
> (3) No grammar contortions (e.g. let) to support sloppy mode.  And
> (4) All new syntax forms with code bodies are implicit strict.

Wow, I like!

Still some friction for 'let' that will retard 'var' replacement but 
it's survivable in my muddy palantir.

> This might seem like a complete giveaway of my previous position. 
>  However, if the above four rules are adhered to, ES6 sloppy mode will 
> be an incomplete, incomprehensible jumble of features and modes.  An 
> insane language, to which the only sane response will be to hang it 
> all and just go all-strict.

If you say so. I suggest sloppy mode will be less used with (4) strict 
bodies than in the case you formerly advocated, due to the friction 
caused by rounding up adoption cost to use-strict conversion of 
surrounding code body.

> Mission f**cking accomplished.

Let's take a breather. I am not out to force anyone into a bitter 


More information about the es-discuss mailing list