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
meaning.
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 block.
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.
Waldemar
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
>> meaning.
>
> 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 block.
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.
Waldemar
On 10/14/10 08:11, Brendan Eich wrote:
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 block.
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.
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 >> meaning. > > 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 block. 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. Waldemar