ES 5, ES 5 Strict reserved words

Brendan Eich brendan at
Mon Mar 7 11:03:55 PST 2011

On Mar 7, 2011, at 10:32 AM, John Lenz wrote:

> In looking over the spec last weekend, I was surprised to see that some reserved words were removed (when compared to ES3) for non-strict and then readded for strict.  I'm confused why this was done.  Doesn't this simply introduce an unnecessary speed bump for moving code to strict?

The problem was that JS-in-reality, at least up to IE8, did not reserve all the "Future Reserved Words" from ES1-3. So ES5 adjusted to be closer to reality, and added more for strict mode, since it is opt-in: Future Reserved Words

The following words are used as keywords in proposed extensions and are therefore reserved to allow for the possibility of future adoption of those extensions.


FutureReservedWord :: one of
    class enum extends super const export import

The following tokens are also considered to be FutureReservedWords when they occur within strict mode code (see 10.1.1). The occurrence of any of these tokens within strict mode code in any context where the occurrence of a FutureReservedWord would produce an error must also produce an equivalent error:

    implements let private public yield interface package protected static

Yes, this is a "speed bump" faced by developers when moving code to strict mode, but there's no way to slow down the JS-in-reality car by changing ES5 non-strict. Browsers will not break the web to conform with a new spec without an opt-in check, and we don't want two levels of opt-in. "use strict" is enough.


More information about the es-discuss mailing list