excluding features from sloppy mode

Oliver Hunt oliver at apple.com
Wed Jan 16 11:00:40 PST 2013


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/6a5f3976/attachment-0001.html>


More information about the es-discuss mailing list