excluding features from sloppy mode

Brandon Benvie brandon at brandonbenvie.com
Wed Jan 16 10:33:22 PST 2013


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 <javascript:;>>
> wrote:
> > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <brendan at mozilla.com<javascript:;>>
> 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 <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130116/ce31c5bf/attachment-0001.html>


More information about the es-discuss mailing list