Given an object literal, or jQuery(html, attributes) object, does any specification state that reserved words, or future reserved words MUST be quoted?
Or, can, for
Given an object literal, or jQuery (html, attributes) object, does any specification state that reserved words, or future reserved words MUST be quoted?
No (starting with ES5).
The definition of property in the spec is that it is any identifier name. class
is a perfectly good identifier name.
As others have pointed out in the comments, according to the spec, the property name in an object literal may be an (unquoted) IdentifierName (in addition to being a string etc.). IdentifierName is, for all practical purposes, any sequence of Unicode "letters", as given in section 7.6.
Note that the syntax error generated by
const {class} = obj;
is not an exception. That's not an object literal, which is what the question is about; it's an assignment (or the destructuring kind), which attempts to assign a variable class
. Of course you can't, never have been able to, and never will be able to have variables which are named with reserved words.
See also this blog post, which although not authoritative is a reliable, high-quality source of information about all things ES5/6/7.
Note that in ES3, the definition of PropertyName was Identifier, not IdentifierName as in ES5. That prevented using properties such as class
, since class
is not an identifier. It was this change that permitted the use of unquoted reserved words as properties in object literals (as well as in dot notation).
With regard to "jQuery objects", a "jQuery object" is just a regular old JS object. Do you mean the DOM elements held by jQuery objects? They are a kind of hybrid of native objects and JS objects. As JS objects, they can have properties. However, they cannot be written in object literal form, so the question does not really apply to them. (As native (DOM) objects, they can have attributes, the latter case not being covered by the JS spec.)
ECMAScript 5+
No, quotes were not needed since ECMAScript 5. Here's why:
As mentioned in your post, from the ECMAScript® 5.1 Language Specification:
7.6 Identifier Names and Identifiers
Identifier Names are tokens that are interpreted according to the grammar given in the “Identifiers” section of chapter 5 of the Unicode standard, with some small modifications. An
Identifier
is anIdentifierName
that is not aReservedWord
(see 7.6.1).[...]
Syntax
Identifier :: IdentifierName but not ReservedWord
By specification, a ReservedWord
is:
7.6.1 Reserved Words
A reserved word is an
IdentifierName
that cannot be used as anIdentifier
.Syntax
ReservedWord :: Keyword FutureReservedWord NullLiteral BooleanLiteral
This includes keywords, future keywords, null
, and boolean literals. The full list is as follows:
7.6.1.1 Keywords
break do instanceof typeof case else new var catch finally return void continue for switch while debugger function this with default if throw delete in try
7.6.1.2 Future Reserved Words
class enum extends super const export import
7.8.1 Null Literals
null
7.8.2 Boolean Literals
true false
The above (Section 7.6) implies that IdentifierName
s can be ReservedWord
s, and from the specification for object initializers:
11.1.5 Object Initialiser
[...]
Syntax
ObjectLiteral : { } { PropertyNameAndValueList } { PropertyNameAndValueList , }
Where PropertyName
is, by specification:
PropertyName : IdentifierName StringLiteral NumericLiteral
As you can see, a PropertyName
may be an IdentifierName
, thus allowing ReservedWord
s to be PropertyName
s. That conclusively tells us that, by specification, it is allowed to have ReservedWord
s such as class
and var
as PropertyName
s unquoted just like string literals or numeric literals.
ECMAScript <5
To go more in depth as to why this wasn't allowed in previous versions before ES5, you have to look at how PropertyName
was defined. Per the ECMAScript® 3 Language Specification:
PropertyName : Identifier StringLiteral NumericLiteral
As you can see, PropertyName
was an Identifer
- not an IdentifierName
, thus leading to the inability for ReservedWord
s as PropertyName
s.
This answer cannot compete with those already given but I'd love to chime in nonetheless.
In my code I prefer to ALWAYS quote keys, for example:
var o;
o = {
"label": "Hello",
"index": 3
};
This way, the problem of strange names or reserved keywords doesn't even arise. Furthermore, all object literals are written in a style that is very near to valid JSON, as an added bonus copy+paste into a separate JSON file (and vice-versa) can be done very quickly.
Today, I consider this a must-have style for clean code.