excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Wed Dec 26 21:32:08 PST 2012

Mark S. Miller wrote:
> On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> 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.

Yes, I agree and I have hopes we are "over the hump" on ES3 => ES5 
(where "use strict"; is meaningful).

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

That is a teleological statement -- you're talking about purpose, 
designed intent, goal, "The Good (Life)".

Very philosophical, I dig it ;-). However, in reality as Dave said in a 
recent message, the Law of Least Effort says people will forget to write 
"use strict"; and we'll have sloppy mode code till the cows come home.

Wherefore my point about pedagogy. But you can't assume teaching will 
eliminate sloppy mode on a definite schedule, or even an indefinite but 
perhaps foreseeable one (~5 years? 10 for sure) wherein pre-ES5 browsers 
die off (including IE9).

>   For any code being actively maintained, it
> should move into strict mode.

Very hortatory, but the kids are alright and they don't all follow a 
single "should". Between dissenters and LoLE or Law of Murphy ;-), I bet 
your "should" will become an ineffectual nag over the next few years.

If, one fine day, virtually everyone does as in Perl and starts their 
programs with "use strict'; (or "module {" with closing "} after), I 
will raise a toast to you and others who helped teach that practice. 
It's nowhere near a certainty, and "should" isn't "would" or "will".

>   Sloppy mode will become a relic only for code no one touches.

Perhaps, but not on a predictable schedule and not (if I'm right) within 
the next few years, when we want ES6 adoption -- including new syntax.

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

Great, we agree -- provided "most" == "all" in my bulleted list, which 
left out 'let' and f-i-b.

> Once we started talking about micro-modes for new function syntaxes,
> it became clear that these do not.

There's no "micro-mode", though. There is simply definite, singular 
semantics for the new syntax, including error throwing.

(I should clarify (Axel misread this and I didn't catch it in replying 
to him in my previous message) that destructuring, etc. in function 
heads does not imply "use strict".)

Again, new syntax speaks for itself. There is no simpler approach, 
because anything else must use a grammar common to strict and sloppy 
modes, but then throw early errors, or create poison-pill functions that 
throw when called, or worse.

Thus I contend that the real mode problem to avoid is one that enlarges 
ES5 strict to include new syntax *and semantics*.

> So for these, if they cannot be
> provided to sloppy mode without micro-modes, they shouldn't be
> provided to sloppy mode at all.

I think you're using "micro-modes" as a curse without actually exploring 
the alternative costs. Destructuring parameters, or default and rest 
parameters, are *easier* to spec (implement) if one does not need to 
write a "am I in non-strict code, including looking ahead to a prologue 
in the body of the function whose head I'm in the midst of evaluating?" 
Such new forms are easier to understand if they speak for themselves, too.

There's no mode-splitting, no extra "if" statements in the spec 

On the other hand, pushing such new forms that can speak for themselves 
into the strict dialect means one must festoon the semantics with extra 

I fear your animus for sloppy mode is overshadowing the costs (or else 
the "new head syntax implies strict body" confusion is in play).

Finally, to connect to the first point, strict mode has some overhead 
(LoLE works against it, people forget to type the directive). I know 
developers who do not use strict mode, but who will rapidly adopt rest 
and default parameters, destructuring in general, and other new forms. 
This adoption of ES6 is partly subjective, distributed over time and 
(head-)space. It should not be yoked to strict mode adoption.

Yoking the two multiplies the likelihood of adoption to get a smaller 
product. That's why I favor implicit strict mode only for bodies of new 
head syntaxes, starting with module as Dave proposed.

I'm ok wtih class opting its body into strict mode, although did we 
decide that one way or the other? I forget.

Arrows we agreed should be strict or not depending on context and (if 
context is sloppy) whether their (block statement) body has a "use 
strict"; directive in its prologue.

Generator functions, as with class, I'm ok if 'function*' implies strict 
body, but this was not agreed to in TC39 meetings, IIRC.

Please let me know if I've misremembered anything.


More information about the es-discuss mailing list