Escape analysis

[Sean Kelly]

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 );
}

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