excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Sat Dec 29 13:11:48 PST 2012

Andreas Rossberg wrote:
> On 29 December 2012 14:51, Axel Rauschmayer<axel at rauschma.de>  wrote:
>> I’m sympathetic to both sides of this argument. How would you handle things?
> Ideally? Backing out of the whole 1JS marketing maneuver?

It's not just marketing surface, but lack of version= substance. How do 
you propose backing out of that? Defining RFC4329 application/javascript 
and application/ecmascript ;version= parameter values and telling people 
to write script tags using those types?

>   In the long
> run, I see it as more harmful than helpful, as it inevitably leads to
> complexity creep, subtle mode mixtures,

Note the V8 team (via MarkM) rightly prefigured 1JS by asking for "no 
more modes" several years ago. Now you want explicit modes? The world 

>   and refactoring hazards that
> are there to stay for eternity. Instead, just make all new features
> strict-mode only and be done with it.

Let's be clear about the refactoring hazards. They do not involve early 
errors. So the only issues are the runtime semantic changes:

* The arguments object in a strict function not aliasing formal parameters.

* Poison pill properties on strict function objects.

* Anything else I'm forgetting.

Is this really that bad in the way of refactoring hazards? Anyone 
refactoring from old to ES6 or later code should get rid of arguments. 
The poison pill properties may be needed so that means don't refactor 
this function, leave it in sloppy mode using function syntax.

What's the big hazard I'm missing?

> But I've accepted that I am in the minority with that opinion, and
> it's too late anyway. Short of that, at least hold the line with
> modules as the only implicit opt-in.

There's a case for class bodies as implicitly strict, you can't dismiss 
it with generalities about refactoring hazards in my book :-P. Care to 
deal with the specific pro-strict-class argument?

>   But in reality I'm pretty sure
> that we will give in to extending the list at some point, if not in
> ES6 then in ES7.

I say all new forms with distinct heads and code-bearing bodies should 
be strict-only.


More information about the es-discuss mailing list