Comments on Meeting Notes

Mark S. Miller erights at
Tue Dec 4 13:08:07 PST 2012

On Tue, Dec 4, 2012 at 1:04 PM, Mark S. Miller <erights at> wrote:
> 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

Obviously, that should have been "...available in non-strict mode at all costs"

> 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
> --
>     Cheers,
>     --MarkM


More information about the es-discuss mailing list