Escape analysis (full scope analysis proposal)

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> I think everyone who thinks a scope decoration proposal is going to 1) 
>>> solve all scope escape issues and 2) be easy to use is dreaming :P
>> I think that's a fair assessment. One suggestion I made Walter is to only 
>> allow and implement the scope storage class for delegates, which simply 
>> means the callee will not squirrel away a pointer to delegate. That would 
>> allow us to solve the closure issue and for now sleep some more on the 
>> other issues.
> 
> If scope delegates means trust the coder knows what he is doing (in the 
> beginning), I agree with that plan of attack.

It looks like things will move that way. Bartosz, Walter and I talked a 
lot yesterday about it - a lot of crazy things were on the table! The 
next step is to make this a reference, which is highly related to escape 
analysis. At the risk of anticipating a bit an unfinalized design, 
here's what's on the table:

* Continue an "anything goes" policy for *explicit* pointers, i.e. those 
written explicitly by user code with stars and stuff.

* Disallow pointers in SafeD.

* Make all ref parameters scoped by default. There will be impossible 
for a function to escape the address of a ref parameter without a cast. 
I haven't proved it to myself yet, but I believe that if pointers are 
not used and with the amendments below regarding arrays and delegates, 
this makes things entirely safe. In Walter's words, "it buttons things 
pretty tight".

* Make this a reference so that it obeys what references obey.

* If people want to implement e.g. linked lists, they should do it with 
classes. Implementing them with structs will require casts to obtain and 
escape &this. That also means they'd be using pointers, so anything goes 
- pointers are not restricted from escaping.

* There are two cases in which things escape without the user explicitly 
using pointers: delegates and dynamic arrays initialized from 
stack-allocated arrays.

* For delegates require the scope keyword in the signature of the 
callee. A scoped delegate cannot be stored, only called or passed down 
to another function that in turn takes a scoped delegate. This makes 
scope delegates entirely safe. Non-scoped delegates use dynamic allocation.

* We don't have an idea for dynamic arrays initialized from 
stack-allocated arrays.

Thoughts? Ideas?


Andrei