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