Is \u006eew a valid Identifier?

Eric Suen eric.suen.tech at gmail.com
Sat Nov 7 16:57:59 UTC 2015


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


More information about the es-discuss mailing list