block scope + direct non-strict eval

Brendan Eich brendan at mozilla.org
Tue Jan 31 11:26:10 PST 2012


Andreas Rossberg wrote:
> On 31 January 2012 19:23, Brendan Eich<brendan at mozilla.org>  wrote:
>> >  I bet the "mode" was what got Sam's attention (mine too) in your "classic
>> >  mode". We are not making hard mode walls or version opt-in. No engine will
>> >  have a mode enum that must be advanced (implicitly or explicitly) and
>> >  checked in order to tell what to do in unversioned script. Or so we think!
>
> I'm afraid that I still fail to get this argument. When you compile an
> individual function in ES6, you will need to have a 3-valued enum
> around saying whether it resides "in strict scope", "in non-strict
> scope", or "in module scope".

But nothing about "classic mode" where new syntax with strict-ish 
semantics is forbidden.

> Similarly, if you are human and read a
> piece of code.

 From my experience with JS developers, I believe that many people will 
read unversioned non-strict code as part of "One JavaScript" (a true 
myth, useful as well as truthful in deep yet fuzzy ways). They won't 
think about strict mode (alas; this may change, but it will take time). 
They definitely will not think about "classic mode". They tell me they 
will use destructuring, spread, rest, etc.

>   No news there. Whether that is called "mode" or
> "context" or something else seems pretty much immaterial.
>
> (I'm saying 3-valued, because Dave was alluding to additional static
> checks inside modules. It may be that 2 values keep being enough.)

If you count "modes" then there could be many, one per new syntax 
use-case in non-strict code. E.g. destructuring formal parameters vs. 
duplicate formals, and how arguments reflects the unnamed object actual 
passed for each destructuring formal pattern. Is that "classic mode"? 
It's not ES5 strict mode.

Modes are not helpful in my view. Teaching people about them is a losing 
proposition, which arguably does a disservice. We may disagree on this 
but I'll be over there with all the JS devs who've rallied around "One 
JavaScript".

/be


More information about the es-discuss mailing list