ES6 doesn't need opt-in

[Brendan Eich]

On Jan 5, 2012, at 8:30 AM, Axel Rauschmayer wrote:

> On Jan 5, 2012, at 1:56 , Brendan Eich wrote:
> 
>> Better to dispense with modes or ordered versions altogether, which is the key idea of the proposal.
> 
> 
> So, simplified, the story is:
> 
> - ES6 is a superset of ES5.strict.

That's always been promised.


> - ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be handled differently.
> 
> If these modes (strict versus non-strict) exist, then I would want a per-file marker for strict code:
> - "use strict";

This doesn't mean Harmony, though. Not now, in ES5 implementations -- it means only ES5-strict. And not in dowrev impls, where it means nothing (and semantics differ at runtime).


> - use strict;

This is a good idea but it was not proposed by Dave to mean Harmony opt-in. Rather, |use module;| was, as a way to avoid bracing and indenting a top level hunk of code in an anonymous module {...} declaration.


> - module {
> 
> 
> Compared to languages such as Java, JavaScript additionally faces the challenge that a developer can’t control what language version is implemented by the browser. How will that be handled? Sketching a solution would provide a more complete picture of how to migrate to ES6.

APIs can be object-detected. New syntax requires autoconf-style eval/Function tests. All doable, nothing mysterious, some try/catch pain required.

I rather expect a boot-loader script will use more coarse-grained means of deciding what to fetch. We had proposed a way to reflect on the maximum supported version (__ECMASCRIPT_VERSION__, IIRC) but that was unsatisfying. More to do here.

/be