Escape analysis

[Andrei Alexandrescu]

Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Wed, Oct 29, 2008 at 11:40 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> Bill Baxter wrote:
>>>> On Wed, Oct 29, 2008 at 7:23 AM, Sean Kelly <sean at invisibleduck.org>
>>>> wrote:
>>>>> Walter Bright wrote:
>>>>>> Sean Kelly wrote:
>>>>>>> I do think, however, that 'scope' should be the default behavior, 
>>>>>>> for
>>>>>>> two
>>>>>>> reasons.  It's backwards-compatible, which is handy.  But more
>>>>>>> importantly,
>>>>>>> I'd say that probably 95% of the current uses of delegates are 
>>>>>>> scoped,
>>>>>>> and
>>>>>>> that isn't likely to shift all the way to 50% even if D moved to 
>>>>>>> a much
>>>>>>> more
>>>>>>> functional style of programming.  Algorithms, for example, all use
>>>>>>> scoped
>>>>>>> delegates, which I'd say is far and away their most common 
>>>>>>> current use.
>>>>>> The counter to that is that when there is an inadvertent escape of a
>>>>>> reference, the error is often undetectable even while it silently
>>>>>> corrupts
>>>>>> data and behaves erratically.
>>>>>>
>>>>>> In other words (as Andrei pointed out to me) the cost of those 
>>>>>> errors,
>>>>>> even though rare, is very high. This makes it highly desirable to
>>>>>> prevent
>>>>>> them automatically, rather than relying on the skill and attention to
>>>>>> detail
>>>>>> of the programmer.
>>>>> I think the cost/benefit of this could probably be argued either way.
>>>>> I've
>>>>> never encountered a bug related to this, for example, so to me the
>>>>> benefit
>>>>> is entirely theoretical while the cost is immediate.
>>>> I've had bugs caused by this but they were pretty easy to find.
>>>> Some delegate I'm calling crashes and all the variables are
>>>> nonsensical garbage...
>>>> Hmm maybe I was using out-of-scope variables in that delegate that I
>>>> wasn't supposed to?
>>>>
>>>> Maybe there are real cases where the bugs caused are harder to find.
>>>> But I'll just add my 2c to Sean's.  I haven't had many such bugs, and
>>>> when I've had them they've been pretty easy to find.
>>> I don't think we can afford program correctness to rest on anecdote 
>>> and "it
>>> works for me". That age is long gone.
>>
>> I haven't seen any real data about how serious a problem this is from
>> you either.
>> Chasing bogeymen is at least as bad as ignoring real problems.
> 
> Well to provide real data I'd have to spend time on user studies, which 
> would be time-intensive. I also think it's not an interesting research 
> problem because it is generally accepted in the community that memory 
> un-safety is a source of problems. So I don't quite feel burdened with 
> the need to provide a proof. Reframing the problem as chasing a bogeyman 
> won't help with addressing it.
> 
> Andrei

I just wanted to issue an apology to Bill for the above, which is 
brusque and demeaning. He was delicate enough to email me privately what 
he thought about my response, and in very levelheaded terms. After 
having answered privately as well, I thought I'd post a public apology; 
it would be quite unethical to apologize in private for a public remark! 
Hopefully this helps with undoing the damage and with keeping the recent 
streak of good discussions going.


Andrei