How is let compatibility resolved?
Never mind, I just realized the let on MDN page is completely different from ES6 let.
It would be easier if we had the other let-specific special forms, wouldn't it?
ES6 draft makes let a reserved identifier. This is not backward compatible, but we're trying to find out what we can get away with. The fallback if we can't reserve is to do what we will do with 'yield (not yet done in current drafts): contextually reserve via parameterized productions, so that in strict code and in module bodies, you can use 'let' to declare (and in generator functions you can use 'yield' as the operator).
On 2 Oct 2013, at 10:45, Petka Antonov <petka_antonov at hotmail.com> wrote:
In current version, this works just fine:
var let = 6;
Note that let
was reserved in strict mode (only) in ES5, meaning that even as per ES5 that snippet only works in sloppy mode.
On Oct 14, 2013, at 9:49 AM, Mathias Bynens wrote:
On 2 Oct 2013, at 10:45, Petka Antonov <petka_antonov at hotmail.com> wrote:
In current version, this works just fine:
var let = 6;
Note that
let
was reserved in strict mode (only) in ES5, meaning that even as per ES5 that snippet only works in sloppy mode.
In my current ES6 editor's draft this is what I have:
"let" is (essentially) reserved in strict mode, so
var let=6;
is a syntax error in strict code.
"let" is not reserved in non-strict mode. So:
var let=6;
is legal in that mode.
Let declarations are contextually identified. A statement with any of these prefixes:
let <identifier>
let {
let [
is parsed as a let declaration.
Any other statement let prefix is treated as an ExpressionStatement. So
let = 7;
or
let++;
are valid ExpressionStatements (in non-strict code).
However, the second statement of:
var let = [ ];
let[i] = x;
will be recognized as a let declaration of an array destructured to i (and throw if the value of x is not an object) rather than an assignment to the i'th property of the array let. To accomplish the assignment, the existing code would need to be modified to read;
(let[i])= x;
Earlier this year we had some web crawl data (thanks, Microsoft) that suggested that this solution wold cause minimal disruption to existing code. However, it still needs to be tested in a real browser.
It might also be helpful for for linters to start looking for the "let [<expr>] =" pattern in non-ES6 flagged code.
In current version, this works just fine:
That could work with let being a contextual keyword.
But how about:
Currently that does:
But if interpreted in ES6 the meaning changes completely.
The above snippets only cause syntax errors in strict mode but work fine in non-strict.
How is this resolved? Will ES6 require some kind of opt-in in a script tag?