Fun impossible Firefox JS challenge

Luke Hoban lukeh at
Thu Apr 12 15:02:47 PDT 2012

>> So, FF (>= 4??) and IE9 don't seem to support unicode escape based de-keywordization and the web doesn't appear to have collapsed.  That seems like a good indication that this isn't a major interp. concern and we can think about what we want such unicode escapes to mean rather than being forced to adopt something.

>> Personally, I think the de-keywordization interpretation is pretty ugly.  It is taking something (unicode escapes) that presumably exist for specific purpose (a way to insert arbitrary Unicode code units into source text) and loads a secondary semantics upon them. I think that ES5 has already covered the important use cases for contextual non-keyword interpretation of reserved words.  If we want to allow declarations that create bindings for reserved words (not something I favor) then we should address that head-on rather than via a ugly backdoor. 

>> I think we should stick with the ES5 intent (Unicode escapes don't change the meaning of an IdentiferName, including keywords) and possibly clarify the Es6 spec. language to make this intent even clearer. 

+1.  Having Unicode escapes have no impact on the interpretation of an IdentifierName seems like a simpler model for the language, and the one that the ES5 spec text currently suggests.  FWIW - I tested IE8 as well, and it also doesn't support Unicode escape de-keywordization, so I suspect this behavior has been around in browsers for quite a while.


More information about the es-discuss mailing list