Escape analysis

[Bill Baxter]

On Thu, Oct 30, 2008 at 12:21 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> 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.

No problem.  My comment leading to that response was a bit snarky too.
 Though I tried really hard not to make it snarky.  It still is
basically saying "I you are but what am I?"

Back to the technical topic, as I told Andrei, all I want is some
solution that doesn't kill performance with lots of hidden memory
allocations.
I doubt that's something anyone really wants, so all this huffing and
puffing about it probably isn't necessary.

--bb