Is \u006eew a valid Identifier?

[Eric Suen]

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
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
"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> 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