Allow use of ES3 future reserved words in dot notation (regardless of option.es5)

[Krinkle]

Words like static and throws are future reserved words since ES3. However the thing about future reserved words (contrary to reserved words) is that to my knowledge no browser anywhere disallowed use of them the way they disallowed reserved words.

In the code I'm currently pluggin in it makes use of a prototype method called throws and property called static.

I ran tests for this against a whole bunch of browsers and they all worked fine:

• Chrome 20-22
• Firefox 3.6-16
• IE6-10
• Opera 11.6-12.0
• Safari 4-5.1

TestSwarm report: http://integration.wmflabs.org/testswarm/job/1

QUnit test runner: http://toolserver.org/~krinkle/tmp/test-js/?module=Prop%20static

And what engines will do in the future doesn't realy matter since from ES5 onwards using them in dot notation is allowed either way.

[goatslacker]

Out of curiosity, where in the spec does it say that using future reserved words in dot notation is ok?

[neonstalwart]

i don't think it's called out explicitly somewhere in a way like "property names may be reserved words".

from http://es5.github.com/#x7.6 you can see what is allowed for an IdentifierName

...and then from http://es5.github.com/#x11.1.5

PropertyName :
    IdentifierName
    StringLiteral
    NumericLiteral

you can see that a PropertyName can be an IdentifierName.

putting all this together, property names can be reserved words.

[goatslacker]

I see:

Identifier ::
  IdentifierName but not ReservedWord

and

ReservedWord ::
  Keyword
  FutureReservedWord
  NullLiteral
  BooleanLiteral

So FutureReservedWord is treated like Keyword. I know you can do var a = { throw: true } but you really shouldn't.

Also const is a FutureReservedWord yet it's implemented in many browsers.

[neonstalwart]

right... but - PropertyName can be an IdentifierName, not to be confused with Identifier which is only the subset of IdentifierName that does not include ReservedWord.

so IdentifierName includes ReservedWord and a property name (which can be an IdentifierName) can include a ReservedWord - make sense?

[Krinkle]

Well.. reserved words are always allowed in dot notation in ES5. No doubt there :) JSHint explicitly doesn't warn for it with option.es5. Things like child.function = function () {}; child.result = { throws: false, expect: 'Hello' }; are perfectly valid in ES5.

The point here is about ES3. We know in ES3 reserved words were not allowed in dot notation. So something like foo.var = 5 would fail under ES3. This mistake was fixed in ES5 (there is no reason not to allow properties to be named after a reserved word, whether or not intentionally, it can't do an operation there anyway. And besides, properties could have any name already, it just meant one had to awkwardly use bracket-string notation for those properties). However foo.throws = 5 works fine under any/all ES3 engines in browsers I could find.

So, pre-ES5 browsers don't seem to consider Future Reserved Words illegal in dot notation, only actual Reserved Words. Meaning, we don't have to emit an error when validating under ES3 when using Future Reserved Words in dot notation. Many people don't even know about Future Reserved Words (and as such just use them), and there was no reason to believe otherwise as apparently browsers didn't care either.

[neonstalwart]

sorry... i just assumed ES5.