excluding features from sloppy mode
rossberg at google.com
Thu Jan 17 05:11:28 PST 2013
On 16 January 2013 19:33, Brandon Benvie <brandon at brandonbenvie.com> wrote:
> Without using modules as the indicator, how do you know whether code is
> intended to be run as ES6 or not? Do let and const count as ES6
> (retroactively applying to code using the old non-standard versions, which
> are still currently supported by V8 and Spidermonkey)? Does it apply to code
> that appears to use Map, WeakMap, and Set (though the code might well refer
> to shimmed versions of these and not otherwise expect to run as strict)?
Fair point that I should clarify: when I said ES6 features I really
meant ES6 language constructs. Libraries are fine, of course.
So yes, 'let' and 'const' count as ES6. That doesn't keep
implementations from providing them as sloppy mode language extensions
as they do now, for their own backwards compatibility. There would be
no reason to use those in new code, though.
One particular advantage of this is that we don't have to break the
web for things like 'const' and 'function' in blocks. Existing
implementations of those features are a horrible, inconsistent mess,
but one that is dangerous to touch. Only cleaning it up in strict mode
where we can safely do so (and remaining oblivious in sloppy mode) is
likely to cause much less problems.
> While there are many things that will absolutely indicate intention to run
> as ES6, there's a number of examples of ambiguity that make me doubt how
> successful an absolute judgment can be. This is why I think giving modules a
> double use as implicit opt-in/pragma has merit.
How does making certain constructs opt in implicitly resolve any of
the ambiguities you mentioned?
> On Wednesday, January 16, 2013, Andreas Rossberg wrote:
>> 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)
>> > 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
>> > mode.
>> > 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
>> > position?
>> es-discuss mailing list
>> es-discuss at mozilla.org
More information about the es-discuss