Nested functions should be exempt from sequential visibility rules

[Nick Sabalausky]

"Don Clugston" <dac at nospam.com> wrote in message 
news:jlelnn$tm4$1 at 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. 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; }

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.