Full closures

BCS ao at pathlink.com
Fri Aug 15 09:42:34 PDT 2008


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.





More information about the Digitalmars-d mailing list