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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
