Escape analysis

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Oct 27 21:24:27 PDT 2008


Robert Fraser wrote:
> 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'.)
> 
> I get the feeling that D's type system is going to become the joke of
> the programming world. Are we really going to have to worry about a
> scope unshared(invariant(int)*) ...? What other type modifiers can we
> put on that?

This is a misunderstanding. Scope is a storage class, not a type
modifier, so it's not as pervasive as you may think.

Andrei



More information about the Digitalmars-d mailing list