Escape analysis

[Sean Kelly]

Bill Baxter wrote:
> On Wed, Oct 29, 2008 at 1:04 AM, Sean Kelly <sean at invisibleduck.org> wrote:
>> Andrei Alexandrescu wrote:
>>> Escape analysis is a tricky business. My opinion is that we either take
>>> care of it properly or blissfully ignore the entire issue. That opinion may
>>> disagree a bit with Walter's, who'd prefer a quick patch for delegates so he
>>> returns to threading. I think if we opt for a quick patch now, it'll turn to
>>> gangrene later. Among other things, it will hurt the threading
>>> infrastructure it was supposed to give precedence to.
>> Like const, I'd rather have no solution than a bad solution insofar as
>> escape analysis is concerned.
> 
> The only serious problem people have right now is that closures are
> allocated automatically when they may not need to be.
> 
> Making closure allocation manual for now seems like the most
> future-compatible way to fix things.  In some nebulous future, the
> manual allocation could become unnecessary, or it could become
> compiler-checked, but it seems to me that for now just making it
> manual does the least harm and lets Walter get back to work on other
> things.

This would be the most backwards-compatible way also.  The only real 
argument against it in my mind is that it makes the default behavior the 
unsafe behavior.  I don't think this is a big deal given what I see as 
the target market for D, but then I don't see a point in SafeD either, 
for the same reason.  The syntax seems like it should be pretty 
straightforward: use 'new' (Andrei will love that ;-)):

     void fn( int delegate() dg );

     void main()
     {
         int x;

         int getX() { return x; }

         // static closure
         fn( &getX );

         // dynamic closure
         fn( new &getX );
     }

That said, the fact that some function calls will always be opaque 
suggests to me that automatic escape analysis will never be possible in 
all situations.  Therefore, we'll likely need something roughly similar 
to the proposed keyword eventually.  So perhaps it really is worth 
considering adding some sort of 'noscope' storage class now:

     // generates a dynamic closure
     noscope int delegate() dg = &getX;

I do think, however, that 'scope' should be the default behavior, for 
two reasons.  It's backwards-compatible, which is handy.  But more 
importantly, I'd say that probably 95% of the current uses of delegates 
are scoped, and that isn't likely to shift all the way to 50% even if D 
moved to a much more functional style of programming.  Algorithms, for 
example, all use scoped delegates, which I'd say is far and away their 
most common current use.


Sean