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