I can explain what V8 is doing/planning to do: The classic behaviour for const is fairly similar to the one from Mozilla, the inventors of const. The implementation is fairly complicated, involving a magic sentinel that enables the implementation to distinguish between a const variable that has not been initialized and one that has been initialized to undefined. Using const disables optimization except in some very simple cases. const declarations are hoisted to function level. This is unfortunately not the same as Safari, which just implements it as a synonym for var.
In <script type=harmony> mode we plan to support the new non-hoisted semantics. In order to prevent a silent change of semantics caused by an update of Chromium we don't plan to change the hoisting semantics in classic mode. It is possible that we might make a change to align with Safari's implementation which is slightly less risky (and a nice simplification). In order to prevent a silent change of semantics caused by addition of 'use strict' we don't want to disable hoisting on strict mode. Instead we ban const in strict mode. The reasoning is: In order to prevent a silent change of semantics caused by addition of <script type=harmony> we make const a syntax error in strict mode code. That way, when people add <script type=harmony> (presumably instead of 'use strict') there won't be any const keywords left in their code. 2011/11/16 Andy Wingo <wi...@igalia.com>: > Hi again, > > Please excuse my ignorance, but: > > On Tue, 2011-11-15 at 07:41 -0800, Brendan Eich wrote: > >> To quote Waldemar from >> >> https://mail.mozilla.org/pipermail/es-discuss/2010-October/011972.html >> >> "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." > > So the current idea is that ES.next has different syntax and semantics, > and so in general the strategy would be to offer <script type="harmony"> > and otherwise some form of "transpilation". > > But you are also proposing to move some ES.next features into the > existing ES5.1 strict mode already provided by implementations? This > would not be necessary if you relied on "transpilation" when targetting > older hosts. > > Don't get me wrong, I think that adding block-scoped `let' and `const' > to strict mode is the right thing, but the big migration picture is > still a little unclear to me. There seems to be some subset of ES.next > that will be implemented in ES5.1 strict-mode browsers, and some other > subset that will rely on versioning. > > Andy > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
