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 <[email protected]> wrote: > > On Nov 9, 2015, at 6:55 AM, Andreas Rossberg <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
