closures

[Steven Schveighoffer]

On Thu, 16 Jul 2009 13:34:27 -0400, Jarrett Billingsley  
<jarrett.billingsley at gmail.com> wrote:

> On Thu, Jul 16, 2009 at 1:24 PM, BCS<ao at pathlink.com> wrote:
>> Reply to Jarrett,
>>
>>> I think what's going on here is that the compiler will *only* allocate
>>> closures for nested functions. However allocating a closure for a
>>> delegate of a value object would be a nice addition.
>>>
>>
>> This will quickly devolve into the general escape analysts problem and  
>> here
>> there be dragons. I think the correct solution is to say it's  
>> unsupported by
>> calling this an escaping reference bug in the user code.
>
> At least for non-ref-param value types, I don't think it's
> unreasonable to say that &obj.func should allocate a closure.  I mean,
> it's the same as saying
>
> int delegate() dg;
> dg.funcptr = &typeof(obj).func;
> dg.ptr = &obj;
>
> and the last line there would be illegal to return under normal
> circumstances anyway.
>
> But you're probably right that it might just be easier to disallow it
> and force people to write { return f.func(); } instead.  :)

What about syntax to force closure behavior (on or off)?  Not that I have  
any to suggest, but if the compiler is going to remain ignorant about  
escape analysis, then we should be able to supply the intelligence, and  
hacking an extra wrapper function to force behavior seems... well, hackish  
:)

-Steve