Full closures

[Robert Fraser]

BCS wrote:
> Reply to Frank,
> 
>> Like shown in http://d.puremagic.com/issues/show_bug.cgi?id=2043 i
>> think the current full closure implementation should take a redesign.
>>
>> My suggestion:
>> Let D have 2 kind of delegate closures (I don't know how to call this
>> correctly)
>> local delegates and heap delegates
>> local delegate are that from D1 without modifiction.
>> They can access every local variable in the surrounding scope, no heap
>> allocation if the addess is taken. It is expected the adress is not
>> used
>> outside the allowed scope.
>> heap delegates
>> - can only access variables from the surrounding scope, if they are
>> marked as 'const', 'invariant' or 'final'. Which means, they are not
>> expected to changed after initialization.
>> - with instantiation of the delegate, a heap allocated frame is used
>> to
>> store a copy of the reference 'final' varialbles for the delegate.
>> That means in case of a loop, the delegate get a new heap allocation
>> with each iteration.
>> foreach( element; container ){
>> const c = element;
>> logLater( new { writefln(c); });
>> }
> 
> Sounds reasonable. I like that it makes the semantics of referenced 
> variables explicit.
> 
> However I would amend it by allowing access to non const (etc.) function 
> arguments (which would be copied on function entry) and variables who's 
> scope is exactly that of the function.
> 
> void fn(int thisArg)
> {
>  int andThis;
>  {
>    int butNotThis;
>  }
> }
> 
> These would greatly increase the practicality of the design without 
> adding ambiguities.
> On second thought, the function args might be bit of a trick. I could 
> live without them.

Ewww, -- changing the scope of the variable should never change its 
behavior, IMO.