Escape analysis

[Jason House]

Walter Bright Wrote:

> The delegate closure issue is part of a wider issue - escape analysis. A 
> reference is said to 'escape' a scope if it, well, leaves that scope. 
> Here's a trivial example:
> 
> int* foo() { int i; return &i; }
> 
> The reference to i escapes the scope of i, thus courting disaster. 
> Another form of escaping:
> 
> int* p;
> void bar(int* x) { p = x; }
> 
> which is, on the surface, legitimate, but fails for:
> 
> void abc(int j)
> {
>      bar(&j);
> }
> 
> This kind of problem is currently undetectable by the compiler.
> 
> The first step is, are function parameters considered to be escaping by 
> default or not by default? I.e.:
> 
> void bar(noscope int* p);    // p escapes
> void bar(scope int* p);      // p does not escape
> void bar(int* p);            // what should be the default?
> 
> What should be the default? The functional programmer would probably 
> choose scope as the default, and the OOP programmer noscope.
> 
> (The issue with delegates is we need the dynamic closure only if the 
> delegate 'escapes'.)

In D1, local variables implicitly follow a mixed rule:
Objects are noscope
Primitive types are scope
Structs are headscope

Headscope may be a bit of a misnomer because member scope is type dependent.

When it comes to escaping, do we need transitive scope? I currently can't imagine that without allowing some exceptions. That insane path seems to lead to 3 scopes for membervariables...