>> 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. Luke _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
