On 03/04/12 13:51, Nick Sabalausky wrote:
"Don Clugston"<d...@nospam.com> wrote in message
news:jlelnn$tm4$1...@digitalmars.com...
I don't see a way to just declare it as "illegal". How would you detect
that situation in the general case?
It's not easy.
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
We don't *have* to go the route of allowing nested functions to access
forward-referenced variables. We could just limit it to forward-referenced
nested functions.
But it's the same. If you can forward reference a function, you can also
access a variable.
So this code could be illegal for exactly the same reason
it's currently illegal:
Y b() { /+ use the var 'x' +/ }
Y y = b();
X x = ...
If 'x' were a nested function instead of a variable, then *that* we could
decide to start allowing:
Y b() { /+ call function 'x' +/ }
Y y = b();
X x() { ... } // b can access this because this is a nested func, not a var
Of course, as you already pointed out and I replied to elsewhere in this
thread, we'd still have to do something about this scenario:
X b() { return a(); }
X w = b();
X x = whatever;
X a() { return x; }
And I don't think there's any easy solution to that.
I think it's a dead end.
Alternatively, if I understand Timon right, I think he's suggesting that we
could treat "groups" of nested function declarations as "unordered", and any
one other statement/declaration would simply break the "group":
// These three can all reference each other freely,
// but they cannot reference f, x, y or z.
A a() {...}
B b() {...}
C c() {...}
// Something other than a nested function declaration.
// This ends the "grouping" of a, b, and c.
F f = ...;
// These three can all reference each other freely.
// Naturally, these can also reference a, b, c, and f
X x() {...}
Y y() {...}
Z z() {...}
That would allow mutual recursion while neatly avoiding any problems.
Yeah, that'd work. It's a funky rule though.