excluding features from sloppy mode

Brandon Benvie brandon at brandonbenvie.com
Wed Jan 16 11:26:37 PST 2013


The incompatibilities between let/const as implemented in V8 and
Spidermonkey and how they're specified in ES6 are an additional factor:

* Per iteration loop binding (V8 and Spidermonkey don't do this for
let/const).
* TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified
to throw ReferenceError in ES6

I think there's other differences.


On Wed, Jan 16, 2013 at 2:00 PM, Oliver Hunt <oliver at apple.com> wrote:

> let can't be used as an opt in (unfortunately :-( ) as it turns out let is
> used as a variable name in real world code.
>
> Gavin and I briefly toyed with the concept of having let be a contextually
> identified, but that's not doable if you have destructuring assignment in
> sloppy mode.
>
> My feeling is that destructuring assignment in sloppy mode is more of a
> win than let, although i'm not sure how others feel.
>
> Note that this isn't a "opt-in", this is an attempt to try and minimise
> the differences between strict and sloppy modes.  My ideal is that anything
> that can be unambiguously supported in sloppy mode should be.
>
> --Oliver
>
> On Jan 16, 2013, at 10:33 AM, 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)?
>
> 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.
>
> 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
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130116/d8b1be9e/attachment.html>


More information about the es-discuss mailing list