Is \u006eew a valid Identifier?

[Caitlin Potter]

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 <eric.suen.tech at gmail.com> 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 <caitpotter88 at gmail.com> 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 <eric.suen.tech at gmail.com> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> 
> 
> 
> --
> ------------------------------------------------
> Spket IDE - Development Tool for RIA.
> 
> http://www.spket.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151107/057d5387/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151107/057d5387/attachment.sig>