Escape analysis (full scope analysis proposal)

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2008-11-02 19:04:37 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>>> Personally, I'd have liked to have a language where you can be 
>>> completely scope safe, where you could document interfaces so they 
>>> know the scope they're evolving in. This concept of something in 
>>> between is a nice attempt at a compromize, but I find it somewhat 
>>> limitting.
>>
>> I agree. Again, something like this was on the table:
>>
>> void wyda(scope T* a, scope U* b)
>>          if (scope(a) <= scope(b)
>> {
>>      a.field = b;
>> }
>>
>> I think it's not hard to appreciate the toll this kind of user-written 
>> function summary exacts on the user of the language.
> 
> First, I think it's a pretty good idea to have this. Second, I think 
> it's possible to improve the syntax; there should be a way to not have 
> to worry about the scope rules when you don't want them to bother you. 
> Here's something we could do about it...
[snip]

But syntax is so little a part of it. I knew since age immemorial that 
escape analysis is a bitch. I mean, everybody knows. Every once in a 
while, I'd get lulled into the belief that things can get "a little 
pregnant" in a sweet spot where the implementation isn't too hard, 
limitations aren't too severe, and the language doesn't get too complex. 
A couple of weeks ago was the (n + 1)th time that that happened; I got 
encouraged that Walter was willing to tackle the task of writing even a 
context/flow insensitive escape analyzer, and I also got hope from 
"scope" being an easy way to express something about a function. 
Ironically, it was your example that disabused me of my mistaken belief. 
  That leaves me in the position that if someone wants to show me there 
*is* such a sweet spot, they better come with a very airtight argument.


Andrei