Escape analysis

[Walter Bright]

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> First off, the mangled names will be different, so it won't link until you 
>> recompile. This is critical because the caller's code depends on the 
>> scope/noscope characteristic.
> 
> This 'feature' is basically useless ;)  D has no shared libraries, so I 
> don't think anyone generally keeps their stale object files around and tries 
> to link with them instead of trying to recompile the sources.  You are 
> asking for trouble otherwise.

I disagree. The whole idea behind separate compilation and using 
makefiles is to recompile only what is necessary. Encoding the function 
specification into its identifier is a tried and true way of detecting 
mistakes in that.


>> Secondly, passing a scoped reference to a noscope parameter should be a 
>> compile time error.
> 
> OK, so when does a closure happen?  I thought the point of this was to 
> specify when a closure was necessary...
> 
> compiler sees foo(noscope int *x)
> 
> I try to pass in an address to a local variable.  Compiler says, hm... I 
> need a closure to convert my scope variable into a noscope.

Either the compiler issues an error, or it allocates the scoped variable 
on the heap. I prefer the former behavior.


> But the compiler's lack of knowledge/proof about the escape intricacies of a 
> function will cause either a) unnecessary closure allocation, or b) 
> impossible specifications.  i.e. I want to specify that either a scope or 
> noscope variable can be passed in, and the variable might escape depending 
> on what you pass in for other arguments, how do I do that?

You make it noscope. Remember that scope is an optimization.

>>> The most common case I think which will cause unnecessary allocations, is 
>>> a very common case.  A class setter:
>>>
>>> class X
>>> {
>>>    private int *v_;
>>>    int *v(int *newV) {return v_ = newV;}
>>>    int *v() { return v_;}
>>> }
>>>
>>> Clearly, newV escapes into the class instance,
>> Then it's noscope.
> 
> So then to call X.v, the function must allocate a closure?  How does this 
> improve the current situation where closures are allocated by default?

If it's escaping, you MUST allocate it in a way that doesn't disappear 
when the escape happens.


>> We take the conservative approach, and regard "might escape" and "don't 
>> know if it escapes" as "treat as if it does escape".
> 
> Also untenable.  We have the same situation today.  You will have achieved 
> nothing with this syntax except making people write scope or noscope 
> everywhere to satisfy incomplete compiler rules.

The improvement with the 'scope' keyword is it allows the compiler to 
assume that the reference does not escape.