confusing (buggy?) closure behaviour

Sergey Gromov snake.scaly at gmail.com
Fri Dec 12 15:15:09 PST 2008


Fri, 12 Dec 2008 15:24:39 -0500, Zoran Isailovski wrote:

> Denis Koroskin Wrote:
> 
>>>> On Fri, 12 Dec 2008 19:32:03 +0300, Zoran Isailovski
>>>> <dmd.zoc at spamgourmet.com> wrote:
>>>>
>>>> > I'm an experienced C#, Java and Python programmer, and have employed
>>>> > closures (and C# delegates) upon numerous occasions. While  
>>>> experimenting
>>>> > with D closures and delegates, I was stroke by a phenomenon I cannot
>>>> > explain. Here's the code:
>> As a rule of thumb, you shoudn't don't return local delegate from a  
>> function in D1, but you may safely pass them down the call stack.
> 
> I don't think it is restrictive if the compiler prevented a situation
> that would otherwise lead to a run-time error anyway, or worse, weird
> and confusing run-time behavior. In my case, if the compiler couldn't
> SAFELY handle a reference to the argument n outside the enclosing
> function, then, IMO, RETURNING it (but not otherwise using it) should
> be flagged a compilation error. Admittedly, detecting this is a bit
> more involved for the compiler, but not at all restrictive for the
> user.

There are situations where proving that n escapes the function is hard
and requires extensive flow analysis.  It may be impossible to prove
when one module of a large program is compiled separately.  And it may
be impossible to prove for library code where user code is unknown by
definition.  Therefore the decision is left to the programmer.  This is
indeed unsafe, and D2 tries to solve this by introducing full,
heap-allocated closures.  This in turn brings performance problems in
situations where stack closures would be sufficient.  Now significant
effort is made towards allowing stack closures in D2 where it would be
safe.

That said, the full closure feature won't make its way into D1.  D1
closures will stay as they are.


More information about the Digitalmars-d-learn mailing list