digitalmars.D.bugs - [Issue 7459] New: working around nested function declaration order
- d-bugmail puremagic.com (39/39) Feb 07 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7459
- d-bugmail puremagic.com (9/9) Dec 13 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7459
- d-bugmail puremagic.com (21/25) Dec 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7459
- d-bugmail puremagic.com (7/10) Dec 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7459
- d-bugmail puremagic.com (20/20) Feb 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7459
http://d.puremagic.com/issues/show_bug.cgi?id=7459 Summary: working around nested function declaration order Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: spec Severity: enhancement Priority: P2 Component: websites AssignedTo: nobody puremagic.com ReportedBy: timon.gehr gmx.ch 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 } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7459 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 13 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7459Ideally, 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.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 14 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7459... The above code should be a compiler error./compiler/compile/s -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 14 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7459 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 20:38:11 PST --- Another workaround: mixin template A() { void foo() { bar(); } // ok void bar() { foo(); } // ok } void main() { void test() { } mixin A!(); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 06 2013