Escape analysis

Mosfet mosfet at anonymous.org
Tue Oct 28 02:36:34 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?

I agree I think that D will be used only by people like you that 
understand all this shared/scope/mutable/lazy things.
I thought C++ was complex and difficult to learn but I think I was wrong.



More information about the Digitalmars-d mailing list