ES6: strict versus non-strict

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Mar 16 16:38:58 PDT 2013


On Mar 16, 2013, at 3:27 PM, Brendan Eich wrote:

> 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.

My rationale is that arrow functions look like they are part of their containing expression while functions and classes look like distinct entities that are contained within the enclosing function.  From that perspective arrows should be strict consistent with the surrounding context but it is ok for class  to implicitly change the strict mode.

function definition need to follow the established ES5 rules.  generator definitions are minor syntactic variation on function definitions so we apply the same rules.

Some of us hope that in the future most code will appear either within a module body or within a class body so most code will implicitly be strict. 

> 
> 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.
My first cut at specifying 3c is at http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_mar_12_2013&cache=cache&media=meetings:legacyblockfunctiondcl2.pdf 
We discussed it at last weeks meeting and while there were some issues raised I'm still confident that the issue can be resolved.


> 
> 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?

I think my rationale above for arrow functions is an example of avoiding a micro-mode.

However, in the lastest released draft where I specified that class definition bodies are always strict I left the extends expression as using the ambient strictness.  My logic is that while the body is a new explicitly delimited context the extends expression is a part of the surrounding context.  You might argue that making the extends expression always strict would be a "micro-mode".   I'm not excessively attached to this particular design point of the extends clause and won't fight very hard if their appeared to be a consensus to change it.

The precedent established in ES5 is the that function head follows the strictness of the function body and I think we should stick with it.  I suppose this might be a way to argument against how I've spec'ed the extends expression's strictness but a class definition is exactly a function definition and the extends clause isn't part of a "function head".

The hard part of maintaining consistency is deciding which things need to be consistent with which others.  


Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130316/f041fb54/attachment.html>


More information about the es-discuss mailing list