Escape analysis

[Robert Jacques]

On Tue, 28 Oct 2008 08:58:18 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:
> "Walter Bright" wrote
>> 4. notifies the user if a library function parameter scope-ness changes
>> (you'll get a compile time error)
>
> Oh really?  I imagined that if the scope-ness changed it just results in  
> a
> new heap allocation when I call the function.
>
> i.e.  Joe library developer has this function foo:
>
> int foo(scope int *x) {return *x;}
>
> And he now decides he wants to change it somehow:
>
> int *lastFooCalledWith;
> int foo(int *x) {lastFooCalledWith = x; return *x;}
>
> I used foo like this:
>
> int i;
> auto j = foo(&i);
>
> So does this now fail to compile?  Or does it silently kill the  
> performance
> of my code?
>
> If the latter, we are left with the same problem we have now.
>
> If the former, how does one call a function with a noscope parameter?
>
> The more I think about this, the more I'd rather have D1 behavior and  
> some
> sort of way to indicate my function should allocate a heap frame (except  
> on
> easily provable scope escapes).
>
> The most common case I think which will cause unnecessary allocations,  
> is a
> very common case.  A class setter:
>
> class X
> {
>    private int *v_;
>    int *v(int *newV) {return v_ = newV;}
>    int *v() { return v_;}
> }
>
> Clearly, newV escapes into the class instance, but how do we know what  
> the
> scope of the class instance is to know if newV truly escapes its own  
> scope?

Escape analysis also applies to shared/local/scope storage types and not  
just delegates. Consider having to write a function for every combination  
of shared/local/scope for every object or pointer in the function  
signature.