On Jan 16, 2013, at 11:26 AM, Brandon Benvie <[email protected]> wrote:
> 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). let isn't really relevant in sloppy mode, unless we decide to take let over destructuring (which would make me really sad) > * TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified to > throw ReferenceError in ES6 I'm not sure adding TDZ to sloppy mode is feasible for const. OTOH const is such a clusterfoo in sloppy mode i'm not sure what the compatibility story is -- I haven't looked at the different behaviours sufficiently to see if they can be merged. I suspect that they can be as const doesn't suffer quite as badly as block scoped functions. Off the top of my head: * JSC will rebind a const if it's in a const declaration, eg. const x = 5; log(x)/*5*/; const x = 6;log(x)/*6*/; x = 7; log(x)/*6*/; * Opera in the past used const as an alias to var, i don't know their current behaviour I don't know which version of IE picked up const (i'm assuming 10 has it?) and i'm not sure what V8/SM do. --Oliver > > 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
