Strict mode recap

Mark Miller erights at
Mon Mar 31 20:26:00 PDT 2008

For context, a brief summary of the consensus agreement we reached at
the ES committee meeting:

The EcmaScript Committee will produce two official standards documents:
* An ES3.1 standard, to supercede the ES3 standard
* An ES4 standard
Currently, the ES3 spec as written differs from the de-facto ES3 as
implemented by web browsers and as employed by web page authors.
* Both ES3.1 and ES4 seek to be a compatible superset of what Brendan
calls ES3+Reality.
* Both groups will work together to help ensure that ES3.1 be a
compatible subset of ES4, i.e., that ES4 be a compatible superset of
* The ES3.1 spec will be written by modifying the ES3 spec text, which
it will supercede.
* The ES4 spec will proceed along its current lines, and will be
available as a distinct document.
* The ES4 reference implementation (RI), though non-normative, will
serve as the initial bridge helping ensure that these two languages
have the intended compatibility relationships.
* The RI will also serve as the ES3.1 reference implementation -- by
testing the subset of its behavior corresponding to the ES3.1
* When this subset of the RI's behavior differs from the intended
semantics of ES3.1, the ES3.1 WG will alert the ES4 WG, so that we can
work together to repair the subset relationship.

Late Friday, after several people had left, those remaining discussed
an interesting refinement. Before I summarize the refinement, I wish
to stress that these are not yet points discussed with the committee
as a whole.

Until the Friday refinement, both ES3.1 and ES4 were going to
condition certain restrictions on opting in to the language version.
Both would condition further restrictions on opting into "strict
mode". The relationship between ES3.1 strict mode and ES4 strict mode
was unclear.

Late Friday, the ES4 WG presented to the joint group their latest
thinking on ES4 strict mode, essentially as summarized by Waldemar.
These restrictions, and the removal of the static type checking
restriction from ES4 strict mode, makes it essentially compatible with
the restrictions needed by ES3.1. With the exception of two issues, it
seems we could now have the following set of relationships:

a) ES3.1 strict <= ES3.1
b) ES4 strict <= ES4
c) ES3.1 <= ES4
d) ES3.1 strict <= ES4 strict
e) 3/4 ES3+R <= ES3.1
f) Caja <= ES3.1 strict

where "<=" means "subset". The precise definition of "subset" was not
explicitly discussed during the committee meetings, but the intuition
seems compatible with the notion of "fail-stop subset" as defined in
the Caja spec.

#e above means that ES3.1 standard mode would be approximately a
codification of ES3+Reality. In other words, for a browser to be
compatible with the de-facto use of JavaScript on the web, it should
be able to follow the ES3.1 std mode spec faithfully. In fact, the
ES3.1 effort started mostly in order to perform this codification.
ES3+R is a bit misshappen, especially regarding features like
lexically nested functions. The "<=" in #e indicates that ES3.1 will
be a bit larger than ES3+R, in order to be a simpler and better
defined language that includes ES3+R. The "3/4" in #e indicates that
presence in 3/4 of the major browsers (IE, FF, Opera, Safari) was
adequate to be a candidate for inclusion.

This 3/4 notion needs one further bit of refinement. The hard
constraint is not that ES3.1 have an upwards compatible semantics from
3/4 ES3+R, but that it have an upwards compatible syntax. An ES3.1
program should successfully parse on existing most of the current ES3
engines, so that it can inquire about its environment -- by feature
testing and comparing MAX_ECMASCRIPT_VERSION -- and then conditionally
execute code according to what it finds. This is the hardest
constraint separating the ES3* line from the ES4* line.

With this background, let's revisit Waldemar's list.

On Mon, Mar 31, 2008 at 5:02 PM, Waldemar Horwat <waldemar at> wrote:
> Here are the items mentioned for inclusion in strict mode:
>  - Don't turn a null 'this' value into the global object  (if non-strict mode in ES4 doesn't already do this)

Much as I hate this particular privilege escalation hazard, in order
to be >= reality, I think this must be sane only in strict mode. ES3.1
and ES4 should be in complete agreement here.

>  - Throw on writes to read-only properties
>  - Throw on deletes of dontdelete properties
>  - delete o.x when x is not in o but in the proto will throw
>  - Reference before definition causes static errors (in some contexts?)
>  - Function arity checking at run time  (ES4 strict only)

I am at a loss on this one. ES3.1 has no alternative way to implement
variable arity and optional arguments, even in strict mode. OTOH, I
quite understand why ES4 strict wants to enforce this. But these
respective stances break the subsetting we desire. It seems we have
our first hard case for working together to repair the subset
relationship. Ideas?

>  - Disable global variable auto-creation when referencing one from, for example, within a function
>  - Disallow duplicate formal parameters
>  - Disallow duplicate names in object initializers
>  - Disable FunctionObject.arguments (not actually in ES3 but woefully used in practice)
>  - (Maybe) Disallow use of arguments object  (ES4 strict only)

After the official meeting broke up completely, several of us (Lars,
Dave, Jeff, ??) continued talking in the Mozilla kitchen. A proposal
for rescuing the arguments object:

In strict mode, the arguments object would be a read-only array.
In a function mentioning "arguments", all it parameter variables would
be read-only, as if declared with "const".

With these restrictions, the strict behavior would both be a fail-stop
subset of the standard behavior, and be well behaved.

>  - (Maybe) Disallow useless expressions
>  - Prohibit 'with' and locally scoped 'eval'.  Globally scoped 'eval', 'new Function', etc. would still be allowed.

Text by me above is hereby placed in the public domain


More information about the Es4-discuss mailing list