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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: >> > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
