Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich<[email protected]> 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.
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
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.
No, see above.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
