Comments on Meeting Notes

Mark S. Miller erights at
Tue Dec 4 13:04:34 PST 2012

On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich <brendan at> wrote:
> Kevin Smith wrote:
>> I recommend allowing let declarations only in strict mode.  This is the
>> simple, backwards-compatible path.  Strict mode only has a bad reputation
>> because, in ES5, it is restrictive-only.  There are (almost) no carrots
>> leading users there.
> Strict mode has a bad rep for two other important causes:
> * It forks runtime semantics, which requires careful testing in
> pre-ES5-strict implementations. This has been a real-world problem, multiple
> times.

I buy this for old code that needs to just keep working, bugs and all,
without human attention. But strict mode can be opted into
incrementally, per program or even per function. For any portion of
code being actively maintained, the non-strict semantics are a hazard.
Admittedly, today with the co-existence of ES3 and ES5, the forking
issue does create an additional problem, because strict code has to
work non-strict as well in old browsers. But pre-ES5 browsers are
finally starting to fade away for real. By the time ES6 rolls out, I
don't expect much ES6 code to be concerned about also running on ES3.

> * It deoptimizes, e.g. a strict-mode function must be optimized to copy
> actual parameter values into arguments if it could use the arguments object.

This one I just don't buy at all. In a strict function f, f.arguments
is poisoned. f's arguments would only need to be reified if f
statically mentions "arguments" or if f has a statically apparent use
of the direct eval operator. For all other cases, no arguments object
need be created, and therefore no copying is needed.

>>  Leave non-strict as is, and let users opt-in to "let".  An excellent
>> carrot.
> The problem is precisely that users cannot opt into "let" alone by its novel
> syntax. Opting into strict mode may or may not win but it has added costs
> and benefits, and that means let adoption will suffer.

>From what was said at the TC39 meeting, the main "cost" is simply that
strict mode has a bad rep with the community. This bad rep, to the
extent it still exists, is largely superstition. However, the
committee, in fear of this irrationality among the community, is about
to make some bad decisions. This es-discuss list is, perhaps,
adequately representative of the community that if there's an outcry,
not to further cruft up the language for the sake of making ES6
features available in strict mode at all costs, then perhaps we can
get the committee to revisit some of those decisions.

> 1JS wants new syntax to be its own opt-in. The only issue with making let
> work in non-strict code is the obscure let[i] = j; pattern. If no one
> actually wrote such code (it's possible; public web searches by big
> search-engine companies, or at least one so far, found nothing), then we
> should not risk reduced let adoption by yoking it to the heavier burden of
> strict mode.

By the time ES6 is a reality, there won't be anything heavy about
strict mode, except the committee's fear of lingering superstition
among developers.

> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at


More information about the es-discuss mailing list