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