New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Krinkle opened this Issue Oct 6, 2012 · 6 comments

Comments

Projects
None yet
4 participants
@Krinkle
Copy link

Krinkle commented Oct 6, 2012

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

This comment has been minimized.

Copy link
Member

goatslacker commented Oct 8, 2012

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

@neonstalwart

This comment has been minimized.

Copy link

neonstalwart commented Oct 8, 2012

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

This comment has been minimized.

Copy link
Member

goatslacker commented Oct 8, 2012

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

This comment has been minimized.

Copy link

neonstalwart commented Oct 8, 2012

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

This comment has been minimized.

Copy link

Krinkle commented Oct 9, 2012

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

This comment has been minimized.

Copy link

neonstalwart commented Oct 9, 2012

sorry... i just assumed ES5.

@valueof valueof closed this in df03538 Dec 16, 2012

jugglinmike added a commit to jugglinmike/jshint that referenced this issue Oct 21, 2014

Better support for FutureReservedWords.
This commit makes JSHint properly recognize FutureReservedWords both
for ES3 and ES5 environments. From now on, unless option es5 is set,
JSHint will warn about all FutureReservedWord identifiers per
ECMA-262 (Ed. 3). However, it won't warn about such identifiers in
a property context:

	var throws = 1; // Warning
	a.throws = 1;   // No warning

For ES5 it now recognizes strict-mode specific FutureReservedWords:

	//jshint es5:true

	var let = 1; // No warning

	(function () {
		"use strict";
		var let = 1; // Warning
	}());

I also made the parser a bit more tolerant towards FutureReservedWords
in statement labels. So the code below will trigger warning but
still be parsed completely (before it would exit with false positives):

	volatile: for (var i = 0; i < 10; i ++) { break volatile; }

Closes jshintGH-674.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment