Skip to content
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

keywords vs. reserved words #339

Open
lewisje opened this issue May 29, 2016 · 0 comments
Open

keywords vs. reserved words #339

lewisje opened this issue May 29, 2016 · 0 comments

Comments

@lewisje
Copy link

lewisje commented May 29, 2016

TL;DR: In the section titled "undefined and null", "keyword of" should be "reserved word in", and in the section titled "Notation of Keys", all three uses of "keyword" should be "reserved word"; all other uses of "keyword" are good (all in the phrase "new keyword"), because the importance of new in these contexts comes from its use in the language as a keyword, not from being reserved.


MDN is a bit confused on this matter (using the phrase "reserved keywords" and incorrectly stating that of is reserved, unless MDN accepts my revision), but the spec is a bit more clear: Such things as the future reserved word enum and the literals null, false, and true are reserved words, but not keywords, and they still cannot be used as variable names or (before ES5) unquoted property keys.

Furthermore, some words that occupy key positions in language constructs and can therefore be considered "key words" are not reserved at all, like as, of, get, and set; the first two are only key in ES6+, while the other two are used in ES5 shorthand methods.

It also appears, in Microsoft's well-known async-await proposal, that async will not be a reserved word despite occupying a key role in the new async function syntax (although await is in the latest draft spec as a future reserved word).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant