It should be reserved, logically — but the spec does not explicitly forbid this. Unless you take Allen’s “it’s a bold sequence of characters, therefore…” argument, which is all well and good, but is only really explained in the spec in http://tc39.github.io/ecma262/#sec-grammar-notation <http://tc39.github.io/ecma262/#sec-grammar-notation> in the first paragraph — and then further, unicode escapes tend to be eagerly converted, so “appear in a script exactly as written” can be misleading. Explicit static semantics work a lot better for this sort of thing, as they can be easily referenced.
So, in that case, it’s SpiderMonkey with the bug in the case of accessor methods, and Chrome without it, while Firefox behaves correctly with escaped `new . target`, and Chrome doesn’t. > On Nov 7, 2015, at 11:57 AM, Eric Suen <[email protected]> wrote: > > So escaped ReservedWords are not valid as ReservedWords nor > Identifier, what is it then? > > And in export { IdentifierName }, why it's IdentifierName not > Identifier. since IdentifierName only valid as Property in > ObjectLiteral or Method in Class, is there any way to define > ReservedWords as local name? > > 'get'/'set' is ContextuallyReservedIdentifier, maybe that's the reason? > > > On Sat, Nov 7, 2015 at 11:32 PM, Caitlin Potter <[email protected]> > wrote: >> That it works in Chrome is a bug, which will hopefully be fixed by Monday or >> Tuesday! >> >> Per http://tc39.github.io/ecma262/#sec-keywords, “new” is a Keyword, which >> makes it a ReservedWord. >> >> Per >> http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors, >> under the >> “Identifier: IdentifierName but not ReservedWord” section, the second early >> error applies here. This applies to >> `new`, which is always a reserved word. So whenever an Identifier is >> expected, if it contains UnicodeEscapeSequences which result in the same >> StringValue as a ReservedWord, it’s an error. >> >> The spec is similarly explicit in saying that escaped ReservedWords are not >> valid as ReservedWords. Browsers behave differently here (for instance, >> http://jsfiddle.net/jd51pqae/ <<< at the time of this writing Webkit Nightly >> prints the text, while other browsers SyntaxError. in Chromes case, this is >> because it’s tokenized as an Identifier, so the second Identifier “f” is >> unexpected when parsing a MemberExpression. SpiderMonkey is doing a nice job >> of reporting clean errors for this kind of thing, that are easier to >> understand. >> >> There are some odd points though: >> >> 1. ReservedWord restrictions never apply to `get` or `set`, even in >> ObjectLiterals (though currently Chrome fails to treat `g\u{65}t` or >> `s\u{65}t` as an accessor prefix, this is a bug). >> >> 2. In the case of “new.target”, it’s technically legal to write >> `new.t\u{61}rget`, but this mostly just seems like an oversight in the spec. >> >>> On Nov 7, 2015, at 9:50 AM, Eric Suen <[email protected]> wrote: >>> >>> "The ReservedWord definitions are specified as literal sequences of >>> specific SourceCharacter elements. A code point in a ReservedWord >>> cannot be expressed by a \ UnicodeEscapeSequence." - what does it >>> mean? >>> >>> The following code is valid in Chrome, but invalid in firefox and IE. >>> >>> var \u006eew = 1; // \u006e = 'n' >>> >>> and valid in Babel/Traceur, invalid in typescript/esprima... >>> >>> -- >>> ------------------------------------------------ >>> Spket IDE - Development Tool for RIA. >>> >>> http://www.spket.com >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > ------------------------------------------------ > Spket IDE - Development Tool for RIA. > > http://www.spket.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
