Full closures

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Aug 18 09:04:24 PDT 2008


Frank Benoit wrote:
> 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.
> 

Refresh my memory on why would that be wanted. Is it because the 
compiler incorrectly heap allocates some variables in a situation that 
is statically verifiable that such allocation wasn't necessary?
Or is it more of a programmer's help, to avoid him/her making mistakes 
and writing code that inadvertently causes locals to be heap allocated?


> 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); });
> }
> 
> 

Why would we want such version of "heap delegates" that are more 
restrictive in power than D's current full closures?



-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



More information about the Digitalmars-d mailing list