block scope + direct non-strict eval
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
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
More information about the es-discuss