On 10/14/10 08:11, Brendan Eich wrote:
On Oct 13, 2010, at 11:56 PM, Erik Corry wrote:

The semantics for const in Harmony are likely to be silently different
in Harmony from the semantics it has in non-strict current
implementations.  (In particular the current const is hoisted to the
surrounding function, whereas the one in Harmony won't, so the
shadowing will be different.)

Agreed so far. IIRC const in Opera is just a synonym for var.

Given this silent behavioural change it would be advantageous to flush
out existing uses of const before Harmony arrives and gives it a new

Flush out means make developers find all such uses, and do what?

Forbidding const in strict mode would seem to be a way to do that.

If only I knew what "flush out" means. Users may or may not rewrite complex 
const-using code just to enable strict mode.

The problem is even more acute for let-based code -- Mozilla JS (Firefox FE and add-on 
code) uses let heavily. It's a sunk cost, arguably a "good sunk cost" (mostly 
future-proof, even with let becoming like let* not hoisted to block top). I doubt people 
will rewrite to var (which requires careful analysis to avoid collisions where there used 
to be shadowing). They simply won't use strict mode.

But const or let, the idea that "use strict" is so attractive it will cause 
re-sinking sunk costs seems farfetched to me. We'll find out, though, because I do agree 
we should make Firefox's strict mode ban let, const, and function in block for now. I 
hope JSC and V8 do likewise with their IE-workalike function-in-block extension.

It's a judgment call, and I'd take these on a case-by-case basis.  For const 
and let, I see little harm in browsers allowing them now in strict mode with 
the purely non-hoisting (C++-like) scoping rules, particularly if they 
complained when you accidentally declared a variable twice directly in the same 

The main risk is avoiding silent changes to code behavior.  Code which used to 
be an error but becomes valid or which used to be an extension but becomes an 
error are easier to deal with.  Thus an implementation that hoisted a const to 
the top of the block but had a barrier preventing you from using it above the 
declaration would be ok in practice (causing silent behavior changes very 
rarely), while one that also hoisted the const initialization to the top of the 
block without a barrier would be bad.

es-discuss mailing list

Reply via email to