Bug 7459 – Document the workarounds for mutually-called nested functions.

d-programming-language.org/function sez: Unlike module level declarations, declarations within function scope are processed in order. This means that two nested functions cannot mutually call each other: void test() { void foo() { bar(); } // error, bar not defined void bar() { foo(); } // ok } The solution is to use a delegate: void test() { void delegate() fp; void foo() { fp(); } void bar() { foo(); } fp = &bar; } The proposed solution is unnecessarily complicated and non-optimal. Since nested template functions are instantiated with the state of the symbol table of the lexically first instantiation, this is a superior solution: void test() { void foo()() { bar(); } // ok void bar() { foo(); } // ok }

Ideally, the compiler should allow nested functions to call each other. I understand there are some complications with how declarations inside function scope are processed, but is there a way to treat function declarations differently from variable declarations?

(In reply to comment #1) > Ideally, the compiler should allow nested functions to call each other. I agree. Furthermore, ideally the state of the symbol table should the one at the declaration of the template. > I understand there are some complications with how declarations inside function > scope are processed, but is there a way to treat function declarations > differently from variable declarations? There are no complications specific to local declarations, except maybe some kind of conservative definite initalization analysis. I guess it's just not implemented and the spec has been modelled after the implementation. An implementation would have to make sure to handle mixins correctly. (just looking at syntactic properties is not enough to decide whether something can be forward-referenced because of those.) string foo(){ return "foo"; } void fun(){ string gen(){ return "void "~foo()~"(){ return `baz`; } "; mixin(gen()); } The above code should be a compiler error. (Similar examples can be constructed in unordered scopes.)

(In reply to comment #2) > ... > > The above code should be a compiler error. /compiler/compile/s

Another workaround: mixin template A() { void foo() { bar(); } // ok void bar() { foo(); } // ok } void main() { void test() { } mixin A!(); }

The language enhancement to allow this should be filed as a separate bug report. A pull was made to document the current workarounds. https://github.com/D-Programming-Language/dlang.org/pull/561

Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/f88fd0903a24e5746fd82ef260f2d49aaf1683d6 Fix Issue 7459 - Document the workarounds for mutually-called nested functions. https://github.com/D-Programming-Language/dlang.org/commit/aa7d8d6254b2736f21661d6aebbf8b091909e01a Merge pull request #561 from AndrejMitrovic/Fix7459 Issue 7459 - Document the workarounds for mutually-called nested functions.

(In reply to timon.gehr from comment #0) > d-programming-language.org/function sez: > > Unlike module level declarations, declarations within function scope are > processed in order. This means that two nested functions cannot mutually > call each other: > [snip] > > The proposed solution is unnecessarily complicated and non-optimal. Since > nested template functions are instantiated with the state of the symbol > table of the lexically first instantiation, this is a superior solution: > > void test() { > void foo()() { bar(); } // ok > void bar() { foo(); } // ok > } In issue 12578, I'm proposing a language behavior to accept the code.