Claude Pache wrote:
Le 4 déc. 2012 à 22:28, Brendan Eich<[email protected]>  a écrit :

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.


If we allow "let" and destructuring assignment in non-strict mode,

(I'm not sure why anything I wrote about strict mode problems was cited, since you did not repond to the "strict mode has a bad rep for these reasons" points...)

  a
developer will happily use "let" as variable name, then one day they
will write "let[i] = j" (Murphy's law), and get an incomprehensible
failure.

This could happen, but did the developer forget to declare "let" (assign an implicit global)? The odds shrink. All uses of 'let' as an identifier have abbreviated "letter" and stored a unit-length string value, so have not indexed into the value.

We talked about making 'var let' in combination with 'let[i] = j' an error, but we did not want parsing to depend on binding. OTOH we did talk about warnings.

Murphy's Law does govern us, I agree. It says that anything that can go wrong, will go wrong. But this applies to let underutilization if yoked to strict mode. Deciding between the alternative paths is not a matter of simple logic, since it depends on human factors.

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to