excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Mon Dec 31 22:37:00 PST 2012


Mark Miller wrote:
> On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <brendan at mozilla.com 
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=brendan@mozilla.com>> 
> wrote:
>
>     Mark S. Miller wrote:
>
>           As I understood Dave's clarification, 1JS is orthogonal to our
>         decisions about how many of the new features to make available in
>         sloppy mode.
>
>
>     No, Dave explicitly proposed that module be available in sloppy mode:
>
>     https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
>
>     "We can do better, and the way we can do it is with modules. We
>     can introduce module syntax in a backwards-compatible way, and use
>     them as the implicit opt-in for any new semantics [2]."
>
>
> Sorry, I have only been skimming this thread and didn't realize that 
> Kevin had dropped "module". Yes, without even "module" being an 
> implicit strict opt-in, we have a different beast, and one that I 
> don't like.

Cool, good to get back to Dave's o.p.

>     I'm pretty happy with Kevin's compromise. Here it is again:
>
>     (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.
>
>     What do you say?
>
>
> My preference order:
>
> 1)
> 1.a) To the extent clean and practical, new features are available 
> only in strict mode,

Just checking: is this because you want to promote "use strict"; usage?

> 1.b) Lexical f-i-b is available in sloppy mode as it is in ES6 strict, 
> since no browser will prohibit f-i-b syntax in sloppy mode. Better to 
> have the f-i-b sloppy semantics be aligned with the ES6 f-i-b strict 
> semantics.

Agreed, and this requires evangelization. We need an action plan.

> 1.c) modules (both inline and out) implicitly opt-in to strict mode.

Note Kevin had inline modules legal as new syntax only under strict mode 
(via "use strict"; above in same unit, or else via next case), while 
out-of-line module bodies would be strict by definition.

> 1.d) classes implicitly opt-in to strict mode.
> 1.e) nothing else causes an implicit strict mode opt-in.
>
> 2) Like #1 but without #1.d (which I think of as Andreas' position)

Sounds right, but let's let Andreas fend for himself :-P.

> 3) Like #1, but #1.e is replaced with
> 3.e) All code bodies within new function syntax is implicitly strict.
>
> 4) Like #3, but #1.a is replaced with
> 4.a) To the extent clean and practical, new features are available in 
> sloppy mode.
> I take it this is essentially your position and Kevin's compromise 
> position?

Yes, I think so, provided "clean and practical" means no 'let' in sloppy 
mode, per Kevin's item (3).

> 5) Where things stood at the end of the last TC39 meeting, where we 
> were violating the "clean" of #4.a to kludge things like "let", 
> non-duplicated-formals-sometimes, no-arguments-sometimes, weird 
> scoping for default argument expressions, etc, into sloppy mode.

Good to call this item (5) out. It needs more discussion. Whatever 
micro-modes mean, if we make new syntax in sloppy mode affect semantics 
of surrounding code, e.g., of the whole parameter list due to just one 
formal using destructuring, then we indeed have a difference from your 
1-4 including sub-items.

I still think such non-local effects could be worth it, but they are a 
separate item from the others, especially your (4.a), the grand K-B 
compromise ;-).

> 6) Like #2 but without #1.c. Is this essentially Kevin's 
> pre-compromise position?

Not quite, as noted above Kevin really meant "no new syntax outside of 
strict code", so an inline module would have to nest directly in a "use 
strict";-governed code body, or else nested directly in an out-of-line 
module body. I.e., only out-of-line module bodies were implicityin (not 
opted into, nothing optional about it :-P) strict mode.

Thanks for the detailed order of preferences. Could you say a bit more 
about your rationale for this order?

/be


More information about the es-discuss mailing list