Escape analysis

[Sean Kelly]

Sergey Gromov wrote:
> 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.

So are you saying that I'd have to rewrite fnA as:

     void fnA( noscope S* s ) {...}

I guess I can see the point, but that's horribly viral.  Particularly 
when classes come into the picture.  With this in mind, from a syntax 
standpoint I'd be leaning towards what D does right now (ie having 
noscope as the default), but from a performance standpoint this is 
absolutely not an option--I may as well just switch to something like Ruby.


Sean