Just Two Modes
This is a long thread and I've been completely busy with other things so
have not had time to do more than skim. So please understand if the post
below misses some context. The following is a summary of some principles
that Dave and just agreed to in a verbal conversation, but he hasn't had
the chance to look at the following text before I send it, so it may not
quite speak for our agreement -- I've substantially elaborated it since the
text that Dave and I looked at together. Dave introduced this thread with
the slogan "just one JavaScript", so I'll introduce the following with the
(much less catchy) slogan "just two modes".
* ES5's strict vs non-strict distinction remains the only mode distinction.
ES6 thus has only the same two modes.
* ES6 non-strict mode must be practically upwards compatible from ES5
non-strict mode.
* ES6 strict mode must be practically upwards compatible from ES5 strict
mode.
* In ES6, one can opt-in to strict mode in at least the following two ways:
"use strict"; // exactly as in ES5
or
module <ident>? {
in statement context. In other words, exactly as ES5 may begin strict mode
at a function boundary to apply to everything recursively contained
lexically within the function, in ES6 in addition, strict mode may also
begin at a module boundary and apply to everything recursively within the
module. Code recursively contained within a module is always strict;
there's no way to write non-strict code within a module. But a module, like
a function, may be embedded within a non-strict context.
* Code that contains such a module construct may run on an ES5 system or
may cause an early SyntaxError, depending on whether this ES5
implementation has been extended to recognize the module construct. An ES6
system must of course recognize the module construct. Thus, modules, as
well as most other features of ES6, may be deployed incrementally, just as
many features of ES5 were deployed incrementally in the transition from ES3
to ES5.
* We give up typeof reform.
* We do completion reform only if we judge it to be practically upward
compatible, with a dispensation to ES5 implementations to implement it
without penalty of being non-conformant. (Dave and I both expect it will in
fact be practically upwards compatible.)
* As with completion reform, if there are other cleanups we can make to ES5
that is practically upwards compatible, e.g., whose only incompatibility is
with test262, we can consider these for ES6 and absolve ES5 systems that
adopt these cleanups.
* We obtain a clean top level scope only by using loaders, which is
increasingly how I've been thinking of SES anyway.
* The identifiers that are reserved in ES5 only in strict mode are:
implements, interface, let, package, private, protected, public,
static, yield
ES6 features that use these keywords are available only in strict mode.
Because ES5 reserved them, this is fully upwards compatible with ES5. For
other ES6 features that do not depend on these keywords, whether or not
they must also be available in ES6 non-strict code we need to take on a
case by case basis.
* In ES6, nested named function declaration must be accepted and have the
agreed ES6 semantics in strict code. As advised at <
http://wiki.ecmascript.org/doku.php?id=conventions:no_non_standard_strict_decls>,
all major browsers currently reject nested named function declaration in
strict code, so accepting them with the agreed semantics in ES6-strict is
fully upwards compatible.ES6 remains as silent as ES5 about whether nested
named function declarations can appear in non-strict code or what their
semantics is there.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
