Tracking identifier restrictions across JavaScript specifications is essential for writing forward-compatible and backward-safe code. The following overview documents how reserved keywords have evolved from the initial ECMAScript 1 specification through ES2015, highlighting shifts in language design and parsing constraints.

ECMAScript 1 (1997)

The inaugural specification established a foundational set of parser tokens. These terms were prohibited from acting as variable or property identifiers:

do, if, in, for, new, try, var, case, else, enum, null, this, true, void, with, break, catch, class, const, false, super, throw, while, delete, export, import, return, switch, typeof, default, extends, finally, continue, debugger, function

ECMAScript 2 (1998)

Version 2 expanded the restriction list significantly, incorporating lexical tokens commonly found in statically-typed languages like Java and C++. These additions included type declarations, access modifiers, and synchronization primitives:

int, byte, char, goto, long, final, float, short, double, native, public, static, throws, boolean, package, private, abstract, volatile, interface, protected, transient, implements, instanceof, synchronized

ECMAScript 3 (1999)

This revision maintained full parity with the ES2 keyword set. No additions or removals occurred during this maintenance cycle.

ECMAScript 4

A formally released ES4 specification was never published. Its experimental features were eventually scaled back and integrated into the subsequent ES2015 release after extensive community feedback.

ECMAScript 5 (2009)

ES5 refined the keyword landscape by removing many legacy type modifiers that never gained traction in dynamic scripting. Conversely, it introduced let and yield as restricted identifiers. Notably, several tokens—including implements, let, private, public, interface, package, protected, static, and yield—were banned exclusively in strict-mode execution contexts. Additionally, eval and arguments behave similarly to reserved words; they cannot be assigned or rebound under strict validation.

While not formally reserved, global properties such as NaN, Infinity, and undefined became read-only or non-configurable in ES5. Assigning to these variables silently fails in strict mode and remains ineffective otherwise. Developers should treat them as immutable constants.

ECMAScript 6 / ES2015 (2015)

The latest major specification broadened identifier restrictions. The previously strict-mode-only limitations on let and yield were lifted, making them invalid everywhere except specific syntactic positions where yield functions as an operator. Furthermore, await was designated as a future reserved word within module execution contexts, preparing the parser for asynchronous functionality.

Programmatic Validation Pattern

To automate checking against historical restrictions, developers often structure keyword data dynamically rather than relying on static lists:

const identifierConstraints = {
  baselineTokens: ['do','if','in','for','new','try','var','case','else','enum','null','this','true','void','with','break','catch','class','const','false','super','throw','while','delete','export','import','return','switch','typeof','default','extends','finally','continue','debugger','function'],
  legacyExpansions: ['int','byte','char','goto','long','final','float','short','double','native','public','static','throws','boolean','package','private','abstract','volatile','interface','protected','transient','implements','instanceof','synchronized'],
  modernRestrictions: ['let','yield','eval','arguments'],
  futureModules: ['await']
};

function validateSyntax(candidateName, requiredEra = 'baseline') {
  const activeSet = identifierConstraints[requiredEra] || identifierConstraints.baselineTokens;
  const mergedWhitelist = [...activeSet, ...identifierConstraints.modernRestrictions];
  return !mergedWhitelist.includes(candidateName);
}

Implementation Recommendations

Avoiding reserved terminology for variable and property naming remains the safest practice. Even archaic tokens from early releases maintain parsing precedence in legacy engines. Strippnig these terms from your identifier vocabulary guarantees interoperability across all runtime environments without requiring version-specific linting rules.