Actually, I think the compiler may be right here. Your code invokes undefined behavior but is otherwise legal and the compiler has every right to successfully compile this into a program that crashes without complaining.

Let me explain:
What you're seeing is an unfortunate side-effect of the combination of lazy [void delegate()] arguments with the fact that a function name doesn't evaluate to a pointer/delegate to that function but to its return value (i.e. property syntax).
Your 'add( fn );' adds an implicit delegate that calls this.dg() (because of property syntax). (It's equivalent to 'add( { fn() } );')
Since this implicit delegate refers to the stack frame of the constructor, it's invalid after the constructor returns. Your call() then calls an invalidated delegate, and your program crashes.

So as you mentioned, to do what you want you should use 'add( &fn );'.
What you didn't realize was that the _reason_ this works is that you're then passing a method delegate instead of an (anonymous) inner function delegate.

d-bugmail@puremagic.com wrote:
>
> What you're seeing is an unfortunate side-effect of the combination of lazy
> [void delegate()] arguments with the fact that a function name doesn't evaluate
> to a pointer/delegate to that function but to its return value (i.e. property
> syntax).

And here I thought lazy parameters had to be marked 'lazy'.  That's 
annoying.  Thanks :-)

Sean Kelly wrote:
> d-bugmail@puremagic.com wrote:
>>
>> What you're seeing is an unfortunate side-effect of the combination of 
>> lazy
>> [void delegate()] arguments with the fact that a function name doesn't 
>> evaluate
>> to a pointer/delegate to that function but to its return value (i.e. 
>> property
>> syntax).
> 
> And here I thought lazy parameters had to be marked 'lazy'.  That's 
> annoying.  Thanks :-)

This is the one exception where 'implicit lazy' was kept when the 
keyword was introduced.

I have expanded the example to show a bit more of the problem an end user can have (sorry I have tango hard-coded, just replace with printf):

import tango.io.Stdout;

void another() {
  Stdout("Another one\n");
}

class C
{   
    this()
    {   
        add(&fn );     // Needed here
        add(another);  // Not needed here!!!!
    }

    void fn()
    {   
        Stdout( "hello\n" );
    }
}

class Elem
{   
    void delegate() proc;
    Elem next;
}

Elem first;

void add( void delegate()[] procs... )
{   
    foreach( p; procs )
    {   
        auto e = new Elem;
        e.proc = p;
        e.next = first;
        first = e;
    }
}

void call()
{   
    for( Elem e = first; e; e = e.next )
        e.proc();
}

void main()
{   
    auto val = new C;
    add(another);     // Not here!
    call();
}

This code works because by trial and error I have put the "&" in the right places. Can this kind of segfault be avoided be detecting it at the compile stage?

Regardless of the answer, I think a diagram (or more details) of what Frits explains in the first reply would help me understand. Thanks.

d-bugmail@puremagic.com wrote:
> I have expanded the example to show a bit more of the problem an end user can
> have (sorry I have tango hard-coded, just replace with printf):
> 
[snip]
>     this()
>     {   
>         add(&fn );     // Needed here

Correct

>         add(another);  // Not needed here!!!!

This happens to look like it does what it should, but in reality it 
still ads a delegate that will be invalid after the constructor returns. 
That delegate just happens not to reference the stackframe of the 
constructor, and thus not crash, because all it does is call a free 
function.
It's still undefined behavior, but undefined behavior doesn't 
necessarily means it'll crash (just that it *may* crash, or worse, and 
if it does it's your fault).

Also, adding a & won't help in this case, as it'll be a function pointer 
instead of a delegate...

>     }
[snip]
> void main()
> {   
>     auto val = new C;
>     add(another);     // Not here!

Correct, but only because the implicitly formed delegate literal happens 
not to go out of scope before it's last called. If for instance the 
module had a 'static ~this()' that would call 'call()' after main ended, 
it'd be undefined behavior.

>     call();
> }
> 
> This code works because by trial and error I have put the "&" in the right
> places.

That's not really the right strategy...
Just because it doesn't crash doesn't mean it does what you think it 
does, or that it won't crash the next time you upgrade/switch compilers 
(or just change which command-line switches to give to your current one)...

 > Can this kind of segfault be avoided be detecting it at the compile
> stage?

At least partially, yes. Google for "escape analysis" (Mostly applied to 
pointers, which have essentially the same problem when pointing to local 
variables).
It may not possible to catch 100% of all cases (without false positives) 
though, and it might be a lot of work to implement (not that I'm an 
expert in this).

> Regardless of the answer, I think a diagram (or more details) of what Frits
> explains in the first reply would help me understand. Thanks.

I'm not really good with diagrams.
Just remember: don't use delegates to local functions/delegate literals 
(including the implicit kind discussed here), pointers to local 
variables or references to 'scope' objects after the function they were 
created in returns.

In the context of the example above, here is another flavor:

class C
{   
    this()
    {   
        add({Stdout("inline").newline;})
    }

... [rest as above]

Would this add a delegate that will be invalid after the constructor returns and thus I should avoid doing it?
If yes, is this something that would ever be changed in D such that is would be "okay" to do?

Thanks.

This is working as designed, although it is bug prone.
It might be possible for the compiler to convert a delegate that calls a member function into a delegate to the member function, avoiding this bug.

(In reply to comment #7)
> This is working as designed, although it is bug prone.
> It might be possible for the compiler to convert a delegate that calls a member
> function into a delegate to the member function, avoiding this bug.

It was not working as designed, but is now. The current behavior (DMD 2.057) is what Sean expects. This is because implicit conversions to void delegate() have been scrapped. Safe to close now.