Bug 7585 – functions in templates inferred as delegate

extern(C) alias void function() Callback; template Wrap(alias dg) { extern(C) void Wrap() { dg(); } } void main() { Callback cb = &Wrap!( () {} ); } Error: cannot implicitly convert expression (&Wrap) of type void delegate() pure nothrow @safe to extern (C) void function() According to Timon Gehr: "'() {}' should be inferred as void function()pure nothrow @safe." http://forum.dlang.org/post/[email protected]

The root cause is conservative escape analysis for nested template instantiation. extern(C) alias void function() Callback; template Wrap(alias dg) { extern(C) void Wrap() { dg(); } } void f1(){} void main() { static void f2(){} void f3(){} Callback cb1 = &Wrap!(f1); // OK Callback cb2 = &Wrap!(f2); // OK Callback cb3 = &Wrap!(f3); // NG Callback cb3 = &Wrap!((){}); // NG } Current implementation always treats lambda literal as nested symbol.

I would hate to stop the implementation of a useful feature, but isn't this against the current spec? http://dlang.org/expression.html#FunctionLiteral "If the keywords function or delegate are omitted, it defaults to being a delegate." Ali

TDPL says that it's inferred.

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/65fe59384a05de9e59cda85f0de8296d6fc9c478 Merge pull request #767 from 9rnsr/fix7585 Issue 7585 - functions in templates inferred as delegate

Just a reminder: the spec needs to be updated.

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/181fb9cd10cf11f20feb22ee13e305f41f9cbe90 Revert "fix Issue 7585 - functions in templates inferred as delegate" This reverts commit 182edee285f9c7b8c552e5de3c11636aac154991.

A new pull to retry fixing: https://github.com/D-Programming-Language/dmd/pull/982

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/24b83f373e93fc553e42213132adabb992c03405 fix Issue 7585 - functions in templates inferred as delegate https://github.com/D-Programming-Language/dmd/commit/c66af72bd96110c027db69ea560b6dc3f88b3054 Merge pull request #982 from 9rnsr/fix7585 Issue 7585 - functions in templates inferred as delegate

What's the state of this? OP sample works, but in Kenji's Comment #1 sample the line which fails is: Callback cb3 = &Wrap!(f3); // NG

(In reply to comment #10) > What's the state of this? OP sample works, but in Kenji's Comment #1 sample the > line which fails is: > > Callback cb3 = &Wrap!(f3); // NG It is to be expected that this fails. If the OP sample works, I assume this is fixed.

(In reply to comment #11) > (In reply to comment #10) > > What's the state of this? OP sample works, but in Kenji's Comment #1 sample the > > line which fails is: > > > > Callback cb3 = &Wrap!(f3); // NG > > It is to be expected that this fails. If the OP sample works, I assume this is > fixed. I guess he also expects this to fail then: Callback cb3 = &Wrap!((){}); // NG but it doesn't fail.

(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > What's the state of this? OP sample works, but in Kenji's Comment #1 sample the > > > line which fails is: > > > > > > Callback cb3 = &Wrap!(f3); // NG > > > > It is to be expected that this fails. If the OP sample works, I assume this is > > fixed. > > I guess he also expects this to fail then: > > Callback cb3 = &Wrap!((){}); // NG > > but it doesn't fail. This should work. What he wanted to show is that (){ } currently behaves like f3, while it should behave like f1 or f2.

(In reply to comment #10) > What's the state of this? OP sample works, but in Kenji's Comment #1 sample the > line which fails is: > > Callback cb3 = &Wrap!(f3); // NG The sample in comment#1 was shown old broken compiler behavior. > Callback cb1 = &Wrap!(f1); // OK > Callback cb2 = &Wrap!(f2); // OK The Wrap function inside Wrap template is declared with extern(C). So it cannot have any hidden context pointer. And, calling f1 or f2 will not need such extra pointer, then Wrap!(f1) and Wrap!(f2) will succeed to compile. > Callback cb3 = &Wrap!(f3); // NG f3 is a nested function. So the Wrap function should get a hidden context to main function, but it is impossible. Then the instantiation Wrap!(f3) will fail. > Callback cb3 = &Wrap!((){}); // NG This should be compiled. The lambda function (){} has no outer context access, so it should not be treated as nested. But, it had been accidentally done. As a conclusion, current compiler works as expected. This bug is already fixed.