ES6 doesn't need opt-in

Allen Wirfs-Brock allen at
Fri Jan 6 09:45:38 PST 2012

On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote:

> No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode.
> For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. 

Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6.  Then, according to the state machine, a program like:

function f(g) {
   //not the following will produce inconsistent results among common browsers
   if (!g) {
      function g() {return 1}
  else if (typeof g !== 'function') {
     function g() {return 2}
   return g;

will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions.  If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type.

The above is exactly analogies to how any "standard" ES5~ES6 features would be treated.

More information about the es-discuss mailing list