escaping pointer to scope local array: bug or not?

[Robert Jacques]

On Tue, 18 Aug 2009 10:57:50 -0700, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Tue, 18 Aug 2009 13:48:23 -0400, Robert Jacques <sandford at jhu.edu>  
> wrote:
>
>> On Tue, 18 Aug 2009 10:38:50 -0700, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Tue, 18 Aug 2009 13:34:36 -0400, bearophile  
>>> <bearophileHUGS at lycos.com> wrote:
>>>
>>>> Steven Schveighoffer:
>>>>> Another way is to perform escape analysis, but Walter has expressed  
>>>>> that
>>>>> he doesn't want to do that.  It would require an intermediate  
>>>>> interface
>>>>> language for imports where annotations could be added by the  
>>>>> compiler.
>>>>
>>>> Why is that bad?
>>>
>>> I don't think it's bad, but definitely a lot of work.  I would be all  
>>> for it.
>>>
>>> -Steve
>>
>> Actually, it's really bad. Escape analysis requires whole program  
>> analysis. It would be impossible to do incremental compilation or to  
>> ship/sell D libraries in binary format. I'd recomend checking out  
>> http://en.wikipedia.org/wiki/Escape_analysis for an overview of the  
>> issues involved. You can avoid doing whole program analysis by  
>> introducing ownership types and being a bit conservative in what you  
>> allow. There's a (bit confusing) wiki page proposal an how to implement  
>> it at http://www.prowiki.org/wiki4d/wiki.cgi?OwnershipTypesInD.
>
> Admitting I didn't read any of that, I think incremental analysis is  
> possible as long as import files are generated by the compiler  
> post-analysis.  i.e. the compiler is able to alter the function  
> signature indicating escape analysis information.
>
> With something like that, you could still ship in binary format, along  
> with generated import files that describe the function signatures (if  
> one requires building against your product).  In fact, the import files  
> could be a part of the binary files, similar to how java works.
>
> -Steve
>

*sigh* That doesn't work. From the wikipedia article:
> In traditional static compilation, method overriding can make escape  
> analysis impossible, as any called method might be overridden by a  
> version that allows a pointer to escape.
For example: Let's take a 3rd party pre-compiled library with class A and  
function f(A a), neither of which have any escapes. Now create a subclass  
of A, B, which does contain escapes. Does f(B) escape or not?

Now, introducing some ownership types, (scope, stack, heap, shared,  
mobile), gives the compiler / methods the guarantees they need to get over  
this problem.