excluding features from sloppy mode
rossberg at google.com
Wed Jan 16 10:17:27 PST 2013
On 1 January 2013 07:09, Mark Miller <erights at gmail.com> wrote:
> On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> Mark S. Miller wrote:
>> 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.a) To the extent clean and practical, new features are available only in
> strict mode,
> 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.
> 1.c) modules (both inline and out) implicitly opt-in to strict mode.
> 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)
Yes, although I'd even consider removing 1.c inline (matching your
option 6 below).
But what do you mean by "to the extent clean and practical"? In my
humble opinion, only two options are really acceptable at all: either
_all_ ES6 features work only in strict mode (my preference), or _all_
ES6 features work in both modes (how I interpret 1JS). Something
in-between, i.e., deciding inclusion into sloppy mode on a by-feature
basis, is a non-starter in terms of usability and observable
complexity. That is, rather (5) than (4) below.
> 3) Like #1, but #1.e is replaced with
> 3.e) All code bodies within new function syntax is implicitly strict.
I'd be strongly opposed to this (and Kevin's point (4) in general).
> 4) Like #3, but #1.a is replaced with
> 4.a) To the extent clean and practical, new features are available in sloppy
> I take it this is essentially your position and Kevin's compromise position?
> 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.
> 6) Like #2 but without #1.c. Is this essentially Kevin's pre-compromise
More information about the es-discuss