Full closures for D

Reiner Pope some at address.com
Sat Nov 3 01:34:14 PDT 2007


Craig Black wrote:
>> It's not an optimal solution because the "does the function escape" 
>> heuristic captures too many functions.
> 
> You could let the programmer specify explicitly whether or not to make a 
> function a closure or not, maybe with a key word or something.
> 
> 

I would have thought 'scope' would have some role in this. It currently 
means 'allocate on the stack', and (is this implemented yet?) when used 
as a storage class for function parameters, it is supposed to mean, "I 
won't escape this variable". You could extend the "does the function 
escape" heuristic to say, "the function escapes if it is assigned to a 
non-scope variable, or is used as a non-scope argument."

This would behave correctly for what I believe is one of the major uses 
of functions: sort/search/etc with a predicate. These things almost 
never escape the predicate, so they can be written:

T find(T)(ref T[] array, scope bool delegate(T t) matches)
{
     ...
}


     -- Reiner



More information about the Digitalmars-d mailing list