Explicit local copies (was: Re: lexical for-in/for-of loose end)

[Herby Vojčík]

Andreas Rossberg wrote:
>>> let a = [], b = [], c = [], d = []
>>> for (int i = 0, f = function(){ return function() { ++i } }; i<  10;
>>> d[i] = function() { return i }, ++i) {
>>>   a[i] = f;
>>>   b[i] = f();
>>>   c[i] = function(){ return i }
>>> }
>
> But note that the environment in b's closures is not the for-loop
> environment. Instead, it is a local environment, whose parent is the
> for-loop environment. To make that case work, it is not enough to be
> able to modify the [[Scope]] environment of closures -- in general,
> you'd need to swap out arbitrary parts of an environment chain.

Oww, that's a problem. Copies are hard here... refs can do it, but no 
one likes them.

> I am fine with either. So far I have favoured
> fresh-variables-per-iteration, but the current discussion has raised
> some doubts in the back of my mind.

This whole discussion leads me to completely different opinion: what 
about to embrace "explicit is better than implicit" for this case, and 
allow let/const without initializer to create local copy of an outer 
variable?

Then, if you need to capture a value, you write it down (I know this 
appeared to avoid capturing by hand in (function (i) { ... })(i), but 
reusing normal blocks to do it may work, wouldn't it?

It disallows some of the ninjutsu (init-closures will work with 
different i than localized closures), but it will be clearly visible:

   let a = [], b = [], c = [], d = [], e = []
   for (int i = 0, f = function(){ return function() { ++i } }; i<  10;
     d[i] = function() { return i }, ++i) {
     a[i] = f; // this
     b[i] = f(); // and this
     c[i] = function(){ return i } // and this work with loop-level i
     {
        let i;
        e[i] = function () { return i; } // this has local i
     }
   }

> /Andreas

There can be even shorter syntax, like
        e[i] = function () let i { return i; } // this has local i
or
        e[i] = function () { let i; return i; } // this has local i
whoch can avoid need of {} block, but it must be thought of if it is 
possible consistently (the former should, the latter may be questionable).

Herby