Bug 790 – arbitrary lookahead for nested functions

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2007-01-03T17:26:00Z
Last change time
2014-02-15T13:22:22Z
Keywords
spec
Assigned to
bugzilla
Creator
Daniel919

Comments

Comment #0 by Daniel919 — 2007-01-03T17:26:57Z
void main() { int a() { return b(1); } int b(int y = 0) { if (y == 0) return a(); else return y; } b(); } line 2: Error: undefined identifier b If you put the implementation of function a and b outside (into global scope), then it's working. So the lookahead is not working for nested functions.
Comment #1 by smjg — 2007-01-03T19:33:53Z
This is a documented restriction: http://www.digitalmars.com/d/function.html#nested "Unlike module level declarations, declarations within function scope are processed in order. This means that two nested functions cannot mutually call each other:" Demoting to enhancement.
Comment #2 by andrei — 2010-11-26T14:11:51Z
I personally think this should be just closed. Symbols defined inside a functions obey sequential visibility. The decision is left to Walter.
Comment #3 by nfxjfg — 2010-11-26T15:05:03Z
The D1 _and_ the D2 specs say about this issue: "Future directions: This restriction may be removed.". Talk about one hand not knowing what the other hand is doing.
Comment #4 by github-bugzilla — 2012-04-14T22:37:53Z
Commit pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/81a653a519c751973cf810a062e68ce997014a02 Explain how to forward-reference a nested function Response to forum post 2012-4-3, "Nested functions should be exempt from sequential visibility rules" and bug 790.
Comment #5 by clugdbug — 2012-09-27T01:36:05Z
This could be closed as invalid, but I'm changing to a spec bug, and marking as fixed, since the spec was changed.
Comment #6 by smjg — 2012-09-28T18:17:09Z
Adding a workaround to a FAQ page doesn't in any way constitute implementing the requested enhancement.
Comment #7 by clugdbug — 2012-11-12T23:52:06Z
OK, then close as wontfix. It could also be invalid. Makes no difference.