Escape analysis

[Andrei Alexandrescu]

Mosfet wrote:
> 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.

Well I think you were right. The question is how much you spend learning 
things that are actually useful, versus learning gratuitous complexity. 
I think D is much more rewarding per unit of effort invested than C++.

Andrei