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 <bran...@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 <erig...@gmail.com> wrote: > > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <bren...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
