migrating `let' and `const'

Erik Corry erik.corry at gmail.com
Wed Nov 16 04:18:03 PST 2011


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 <wingo at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list