ES6 doesn't need opt-in

Andreas Rossberg rossberg at
Mon Jan 9 02:59:47 PST 2012

On 6 January 2012 03:37, Allen Wirfs-Brock <allen at> wrote:
> Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit
> In an "ES6" implementation, all constructs that can occur in a valid program fit into one of these categories:
> ES6-only:  The construct is based upon syntax or static semantics rules that only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics rules that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> ES5~EAS6:  The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.  For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object.
> We can then use the following state machines to describes the processing of a Program based upon the occurrence for these feature categories.  Initially start in State 5&6:

I think the state machine is over-complicating things. What it boils
down to is that we are defining a new language, ES6-proper (or
informally ES6 for short). It overlaps with ES5 but does not include
it (e.g. throws out `with'). Then your "state machine" simply says,

- If a program is ES5 but not ES6, treat as ES5.
- If a program is ES6 but not ES5, treat as ES6.
- If a program is both ES5 and ES6, with identical semantics, treat as
ES6 (although it doesn't matter).
- If a program is both ES5 and ES6, with different semantics, treat as
ES5 (for compatibility).
- If a program is neither ES5 nor ES6, it's an error (obviously).

I very much like that opt-in would be for whole programs only. I think
that is good, and IMHO progress over some of the earlier discussion.

But still, deciding what semantics a program has can depend on very
minor syntactic details. This has several potential problems:

1. For eternity, we will require future programmers to remember what
exact features were introduced with ES6, in order to be sure that they
trigger the right (i.e. strict) semantics for their program.

2. The syntactic trigger in a given program may be hidden somewhere
deep down the source code, which makes it very difficult to decide for
the reader (and the compiler, which may have to do extra work in the
parser to decide).

3. Apparently minor local modifications may accidentally change the
semantics of the whole program.

The obvious way to avoid all these issues is to always put an explicit
trigger at the top. And I expect that style guides would recommend
that. But that kind of defeats the purpose, doesn't it? I still
haven't heard a convincing argument why it is advantageous to not make
this explicit trigger mandatory.


More information about the es-discuss mailing list