excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Wed Dec 26 21:01:06 PST 2012


Axel Rauschmayer wrote:
>> So, case by case:
>>
>> * arrow function syntax (which does not imply "use strict" in body 
>> prologue)
>> * class
>> * const
>> * default parameters
>> * destructuring
>> * rest parameters
>> * generators (function*, yield in function* body)
>> * comprehensions
>> * generator expressions
>> * module
>>
>> all seem to work in 1JS via the "new syntax is its own opt-in" rule, 
>> including any stricter/saner semantic checking.
>>
>> I left out 'let' and function-in-block. Let's set those aside for a 
>> moment.
>>
>> Anyone disagree that the bulleted syntactic extensions listed above 
>> should be their own opt-in, and think instead that some or others or 
>> all should appear only to strict code? (Mark, here's your chance! ;-)
>
> Am I getting the following grouping right? I’d argue that all members 
> of the second category usually have small bodies; having ES6 syntax 
> only there might make things too fragmented.
>
> (1) opt-in for bodies:
> * class
> * default parameters
> * rest parameters
> * destructuring (parameters?)
> * generators (function*, yield in function* body)
> * module
Right so far.

> (2) opt-in for surrounding scope:
> * arrow function syntax (which does not imply "use strict" in body 
> prologue)

No, there's no reason for such opt-in given 1JS's "new syntax is its own 
opt-in selector". If somewhere else, 3000 lines down, you need a 
comprehension, use it then. No need for the arrow here to enable the 
comprehension there, or vice versa. No enabling outside of the 
syntax-that-enables-itself.

> * const

Already reserved (in some sense, even if equated to var in Opera), no 
opt-in required. This identifier was reserved in ES1.

> * comprehensions

Same as arrows, no surrounding scope taint and no need for it.

> * generator expressions

Ditto.

/be


More information about the es-discuss mailing list