Escape analysis

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Jason House wrote:
>> Walter Bright Wrote:
>>
>>> Jason House wrote:
>>>>> scope is a storage class, not a type constructor.
>>>> How do you treat members of objects passed in? If I pass in a
>>>> struct with a delegate in it, is it treated as scope too? What if
>>>> it's an array? A class?
>>> The scope applies to the bits of the object, not what they may
>>> refer to.
>>
>> This seems rather limiting. I know this is aimed at addressing the
>> dynamic closure problem. This solution would mean that I can't
>> encapsulate delegates. Ideally, I should be able to declare my
>> encapsulating struct as scope or noscope and manage the member
>> delegate accordingly.
>
> I think it's clear that scope is transitive as much as const or immutable 
> are. Noscope is also transitive.
>
> Escape analysis is a tricky business. My opinion is that we either take 
> care of it properly or blissfully ignore the entire issue. That opinion 
> may disagree a bit with Walter's, who'd prefer a quick patch for delegates 
> so he returns to threading. I think if we opt for a quick patch now, it'll 
> turn to gangrene later. Among other things, it will hurt the threading 
> infrastructure it was supposed to give precedence to.

A quick patch is not possible IMO.

What I'd prefer is allocate closure when you can prove it, allow 
specification when you can't.  That is, allocate a closure automatically in 
simple cases like this:

int *f() {int x = 5; return &x;}

And in cases where you can't prove it, default to not allocating a closure, 
and allow the developer to specify that a closure is necessary:

int *f2(int *y){...}

int *f() <insert closure keyword here> {int x = 5; return f2(&x);}

Syntax to be debated ;)

I do *not* think the problem should be ignored (i.e. continue with the 
current D2 implementation).

-Steve