get/set/as/from/target are valid Identifier, it can't be reserved words On Sun, Nov 8, 2015 at 1:06 AM, Caitlin Potter <[email protected]> wrote: > It should be reserved, logically — but the spec does not explicitly forbid > this. Unless you take Allen’s “it’s a bold sequence of characters, > therefore…” argument, which is all well and good, but is only really > explained in the spec in http://tc39.github.io/ecma262/#sec-grammar-notation > in the first paragraph — and then further, unicode escapes tend to be > eagerly converted, so “appear in a script exactly as written” can be > misleading. Explicit static semantics work a lot better for this sort of > thing, as they can be easily referenced. > > So, in that case, it’s SpiderMonkey with the bug in the case of accessor > methods, and Chrome without it, while Firefox behaves correctly with escaped > `new . target`, and Chrome doesn’t. > > > On Nov 7, 2015, at 11:57 AM, Eric Suen <[email protected]> wrote: > > So escaped ReservedWords are not valid as ReservedWords nor > Identifier, what is it then? > > And in export { IdentifierName }, why it's IdentifierName not > Identifier. since IdentifierName only valid as Property in > ObjectLiteral or Method in Class, is there any way to define > ReservedWords as local name? > > 'get'/'set' is ContextuallyReservedIdentifier, maybe that's the reason? > > > On Sat, Nov 7, 2015 at 11:32 PM, Caitlin Potter <[email protected]> > wrote: > > That it works in Chrome is a bug, which will hopefully be fixed by Monday or > Tuesday! > > Per http://tc39.github.io/ecma262/#sec-keywords, “new” is a Keyword, which > makes it a ReservedWord. > > Per > http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors, > under the > “Identifier: IdentifierName but not ReservedWord” section, the second early > error applies here. This applies to > `new`, which is always a reserved word. So whenever an Identifier is > expected, if it contains UnicodeEscapeSequences which result in the same > StringValue as a ReservedWord, it’s an error. > > The spec is similarly explicit in saying that escaped ReservedWords are not > valid as ReservedWords. Browsers behave differently here (for instance, > http://jsfiddle.net/jd51pqae/ <<< at the time of this writing Webkit Nightly > prints the text, while other browsers SyntaxError. in Chromes case, this is > because it’s tokenized as an Identifier, so the second Identifier “f” is > unexpected when parsing a MemberExpression. SpiderMonkey is doing a nice job > of reporting clean errors for this kind of thing, that are easier to > understand. > > There are some odd points though: > > 1. ReservedWord restrictions never apply to `get` or `set`, even in > ObjectLiterals (though currently Chrome fails to treat `g\u{65}t` or > `s\u{65}t` as an accessor prefix, this is a bug). > > 2. In the case of “new.target”, it’s technically legal to write > `new.t\u{61}rget`, but this mostly just seems like an oversight in the spec. > > On Nov 7, 2015, at 9:50 AM, Eric Suen <[email protected]> wrote: > > "The ReservedWord definitions are specified as literal sequences of > specific SourceCharacter elements. A code point in a ReservedWord > cannot be expressed by a \ UnicodeEscapeSequence." - what does it > mean? > > The following code is valid in Chrome, but invalid in firefox and IE. > > var \u006eew = 1; // \u006e = 'n' > > and valid in Babel/Traceur, invalid in typescript/esprima... > > -- > ------------------------------------------------ > Spket IDE - Development Tool for RIA. > > http://www.spket.com > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > ------------------------------------------------ > Spket IDE - Development Tool for RIA. > > http://www.spket.com > >
-- ------------------------------------------------ Spket IDE - Development Tool for RIA. http://www.spket.com _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
