ES6: strict versus non-strict

Brendan Eich brendan at mozilla.com
Sat Mar 16 15:27:30 PDT 2013


Axel Rauschmayer wrote:
> Quoting 
> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
>
>> Consensus on... Stay the course on spec development approach Class, 
>> Modules implicitly strict. Arrows not strict Sustaining our position 
>> on the handling of let ambiguities (Note: this is a local consensus).
>
> I’m completely confused about what will work where. I’d love to see an 
> article/blog post/section in ECMA-262 that explains how all of this 
> (strict vs. non-strict, let, function decls in blocks, etc.) fits 
> together. Given that things are still in flux, now might be too early, 
> but once everything has been settled(?)

The words you cite from Rick are pretty clear on strict: only class and 
module have strict-by-definition bodies. Arrows and generators need "use 
strict" governing them, or in their body in prologue directive position.

On the new syntax is its own opt-in, we have consensus to try 'let' in 
sloppy mode, with Mark Miller noting his distaste but not breaking 
consensus.

On function-in-block vs. 'let'/'const' in sloppy mode, see the 
notes:*Consensus* Allen will spec #3c static semantics with informative 
note for review, tentatively to fallback to #3b. See the options under 
Options.

Option #3: Hybrid semantics for function-in-block:
3a. In both strict and non-strict *No Support*
3b. In only non-strict. Strict keeps ES6 block scope functions
3c. Absolute minimum intersection semantics supported in non-strict, 
else ES6 semantics

Allen is working on 3c, with fallback to 3b.

On new syntax mixing in sloppy function heads, I forget where we landed 
and don't see a clear record. I think I agreed with Andreas Rossberg 
(ARB) that we should not make "micro-modes", but forget what exactly 
that means. Allen?

/be


More information about the es-discuss mailing list