excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Wed Dec 26 22:38:49 PST 2012


Kevin Smith wrote:
> First, maybe the "1JS" term is a bit confusing and should be retired.

You're not in marketing, are you :-P.

(I wasn't for most of my career but ended up doing it 50-50 with talent 
scouting/coaching/nagging. Sucks to be me! :-P)

1JS is too short and tweet-sweet to die.

> I think a few simple rules are in order:
>
> 1) No opt-in required for new syntax, except:
> 2) No breaking changes for sloppy mode.
> 3) No implicit opt-in to strict mode.
>
> Everyone agrees on rule #1.  Rule #2 implies no "let" declarations in 
> sloppy mode, and no breaking block function semantics in sloppy mode. 
>  (Are there others?)

Completion reform, a runtime semantic change. See 
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform.

>  Rule #3 is probably the most controversial, but I think it's important.

Indeed, it goes against Dave's original proposal that module opt into 
strict mode, which avoids some problems with sloppy mode in modules, 
e.g. implicitly created globals by assignment to free names.

> If we have implicit opt-in to strict mode via new syntax:
>
> - Figuring out what code is sloppy and what code is strict is going to 
> end up the domain of language lawyers.  A casual user should not have 
> to know when a particular syntactic feature was added in order to know 
> what are the runtime semantics for that code.  All a casual user 
> should have to know is to put "use strict' at the top of the file.

This is a slippery-slope argument. _Contra_ some controversialists, I do 
not find such arguments fallacious on their face. Lots of bad things 
happened by "boiling the frog" (in real life I'm told the frog jumps out 
in time).

On the other hand, Dave proposed 1JS with *only* module implicitly 
opting its bodoy into strict mode. That is a line we can probably hold.

I suggest (I'm not sure, need to think more) that adding class (and 
perhaps even function*) to the set of "heads" whose bodies are 
implicitly strict wouldn't slide too far down-slope, but going from 1 to 
 >1 is the big bad change. So let's say that only 'module' implies 
strict code in its body.

> - Taking advantage of new syntax (perhaps in the head of a function) 
> will trigger completely unrelated semantic changes.  This feels messy.

That's right, and we (TC39, and es-discuss too IIRC) agreed that new 
function head syntax, whatever it might do in the way of banning 
duplicate formal parameters, does not imply strict mode for the 
function's body.

/be


More information about the es-discuss mailing list