excluding features from sloppy mode

Mark S. Miller erights at google.com
Sat Dec 29 13:23:13 PST 2012

On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>> I haven't replied to this thread yet, because I feel that I already
>> made all the same arguments repeatedly to no avail. ;)  However, let
>> me reiterate one particular observation, which is that IMHO much of
>> the discussion (and decision making) around 1JS, modes, and opt-ins is
>> just mistargeted.
> Could be, let's see.
>> Namely, it is primarily based on the expectations and needs of
>> _current_ users. Users that are aware of what's ES3 or 5 and who are
>> about to investigate what's new in ES6. To those users, design choices
>> like making new constructs opt into strict mode by default will not
>> seem a big deal, even natural.
> Glad to hear some concurrence.
>> But that group will be irrelevant after a relatively short time of
>> transition!
> Who knows? "Relatively short time" will be measured in units of years,
> though.
>> ES6+ will stay much longer (at least that's what we are working for).
>> Consequently, what should take precedence are the expectations and
>> needs of _future_ users of ES. Those who will come to ES6+ without
>> knowing nor caring about the colorful history of its earlier versions.
>> For them, having various features locally change the semantics of
>> unrelated constructs
> Whoa.
> Who ever proposed that? It seems a misunderstanding. No one is saying that,
> e.g., destructuring formal parameters, or a rest parameter, should flip the
> containing function into strict mode. Banning duplicate formals in no wise
> does that.

This is an example of the micro-modes issue. If optional, rest, and/or
destructuring needs to enforce no duplicates, then we have two

1) Make these features available only in strict code, which doesn't
require any new special case -- since strict already bans duplicate
parameter names.

2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity of dealing with one mode switch.

By our previous criteria, #1 is obviously simpler than #2.

> So what exactly are you referring to here, in the way of a live proposal?
> /be


More information about the es-discuss mailing list