Escape analysis

[Sergey Gromov]

Sean Kelly wrote:
> Walter Bright wrote:
>> Steven Schveighoffer wrote:
>>> "Walter Bright" wrote
>>>> The reason the scope/noscope needs to be part of the function 
>>>> signature is because:
>>>>
>>>> 1. that makes it self-documenting
>>> But the documentation is not enough.  You cannot express the 
>>> intricacies of what variables are scope escapes so that the compiler 
>>> can make intelligent enough decisions.  What this will result in is 
>>> slightly less unnecessary closures, but not enough to make a 
>>> difference.  Or else you won't be able to declare things the way you 
>>> want, so you will be forced to declare something that *could* result 
>>> in an escape, but usually doesn't.
>> I think it is conceptually straightforward whether a reference escapes 
>> or not, though it is difficult for the compiler to detect it reliably.
>>
>>>> 2. function bodies may be external, i.e. not present
>>>> 3. virtual functions
>>> Yes, so you are now implying a scope escape contract on all derived 
>>> classes. But not a very expressive one.
> 
> There's another weird issue that I'm not sure if anyone has touched on:
> 
> struct S
> {
>      int x;
>      int getX() { return x; }
> }
> 
> void main()
> {
>      auto s = new S;
>      fn( s );
> }
> 
> void fnA( S* s )
> {
>      fnB( &s.getX );
> }

Part of s escapes, so the compiler should assume that the whole s
escapes.  If s is scope by default, it should be a compile-time error here.

> void fnB( noscope int delegate() dg ) {}
> 
> How does the compiler handle this?  It can't tell by inspecting the type 
> whether the data for S is dynamic... in fact, the same could be said of 
> a "scope" instance of a class.  I guess it would have to assume that 
> object variables without a "noscope" label must be scoped?
> 
> 
> Sean