Comments on Meeting Notes
brendan at mozilla.org
Tue Dec 4 13:28:01 PST 2012
Mark S. Miller wrote:
> On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich<brendan at mozilla.org> 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
> 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.
Real world problem: concatenation.
> 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.
Hard to say what IE8's share will be, but IE9 did not implement strict
mode IIRC. IE10 did.
>> * 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.
Right, that's what I tried to say by "could use the arguments object".
Nothing to do with hated f.arguments.
So every strict function that uses arguments pays a copying price on
entry in a naive implementation. Pushing the copies out till just before
there might be an aliasing store is an optimization that could be done
in a more sophisticated implementation, but engines don't do it
currently and feel little pressure to do so. Chicken and egg.
>>> Leave non-strict as is, and let users opt-in to "let". An excellent
>> 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.
No, see above.
More information about the es-discuss