ES6 doesn't need opt-in

Mark S. Miller erights at google.com
Fri Jan 6 11:23:06 PST 2012


AFAICT, this agrees with my analysis of what your proposal means. How does
this not result in three modes?

On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> 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.
>
> Allen
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120106/04d22061/attachment.html>


More information about the es-discuss mailing list