Is \u006eew a valid Identifier?

[Caitlin Potter]

Per spec, it’s not a keyword

> On Nov 11, 2015, at 2:50 AM, Eric Suen <eric.suen.tech at gmail.com> wrote:
> 
> In Spec it's clear that escaped reservedWords is not Identifier nor ReservedWord
> 
> In https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour <https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour>
> you said it's keywords...
> I said in Jave/C# escaped keywords is keywords, you said JavaScript is
> not Java nor C#...
> 
> In https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121 <https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121>
> "JavaScript parsers differ on whether they interpret escaped sequences
> of letters spelling a reserved word, such as "de\u006Cete", as an
> identifier or a reserved word." that may cause issue.
> 
> Till today still none Engine/Tool parse it correctly, Chrome/babel
> treat it as Identifier, IE 11 and Firefox 42.0 and esprima treat it as
> keywords.
> 
> It's confirm that escaped reservedWords is not Identifier. Can I have
> a final conclusion is it keywords or not?
> 
> On Tue, Nov 10, 2015 at 1:05 AM, Allen Wirfs-Brock
> <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>> 
>> On Nov 9, 2015, at 6:55 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> 
>> Allen, what was the motivation for allowing random escapes in
>> identifiers but not in keywords? AFAICS, it would be simpler and more
>> consistent to allow them anywhere and render "escape normalisation" a
>> uniform prepass before tokenisation. IIUC, that's what other languages
>> do. The current ES rules are far from ideal, and require jumping
>> through extra hoops, in particular, to handle context-dependent
>> keywords like `yield`.
>> 
>> /Andreas
>> 
>> 
>> see:
>> 
>> Here are some references:
>> https://github.com/tc39/tc39-notes/blob/master/es6/2013-11/nov-20.md#42-clarification-of-the-interaction-of-unicode-escapes-and-identification-syntax
>> https://bugs.ecmascript.org/show_bug.cgi?id=277
>> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
>> https://esdiscuss.org/topic/this-vs-thi-u0073
>> 
>> there are many others, and also there were earlier TC39 meeting discussions
>> that I didn’t find in my quick search.
>> 
>> It’s a usability vs. implementor convience trade-off.  the TC39 was to go
>> with usability (and in particular readability).
>> 
>> (Also, my recollection is that in some TC39 discussions (that I didn’t find
>> in my search) there were security concerns raised WRT allowing unicode
>> escapes in keywords. Probably concerns about code injection filters not
>> recognizing escaped keywords)
>> 
>> In ES6 (and I believe that Waldemar would claim in previous editions)
>> unicode escapes cannot be handled with such a prepass. Essentially, escaped
>> and non-escaped IdentifierName characters are only equated when doing
>> identifier binding or property name lookups. It’s probably a misperception
>> of the lexical grammar and static semantics that leads some implementors
>> down the path of thinking that  such a preps is reasonable.
>> 
>> Regarding `yield`, if it is written containing unicode escapes it is never a
>> contextual keyword.
>> 
>> BTW, personally I I would be just fine with never allowing unicode escapes
>> within IdentiferName. But that would be a web breaking change.
>> 
>> Allen
>> 
>> 
> 
> 
> 
> --
> ------------------------------------------------
> Spket IDE - Development Tool for RIA.
> 
> http://www.spket.com <http://www.spket.com/>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151111/6a05c31a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151111/6a05c31a/attachment-0001.sig>