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