Nested functions should be exempt from sequential visibility rules

[Nick Sabalausky]

"James Miller" <james at aatch.net> wrote in message 
news:mailman.1324.1333434077.4860.digitalmars-d at puremagic.com...
>
> [...]the issue
> is with closures, what values should be visible to the closures?

Personally, I don't much care ATM. Either way has it's pros and cons:

A. Same as right now: The nested function can only access variables defined 
before it. Only difference is that it can *also* access "sibling" nested 
functions that are defined before *or* after. The benefit is that there's 
minimal change to the current "sequential visibility".

B. Let nested funcs access *any* "sibling" symbol whether defined before or 
after. Presumably, the nested func would not be *callable* until after all 
the sibling symbols it accesses have been declared. The downside is that, I 
suspect, this might be more work to implement. The benefits are that it 
provides more flexibility and is more consistent with module-level 
declarations. That latter benefit would be import for code like this:

void main() {  mixin(import("script.d"));  }

I guess I would lean more towards "B", but it is a bigger change and I 
realize bigger changes meet bigger resistance at this point. So I'd be 
content either way because what's *more* important here is we ditch the 
(seemingly) silly restriction of "no mutually recursive nested funcs".

'Course, another approach would be to just for the compiler to treat this:

void foo()
{
    /+ code 1 +/
    void a() {...};
    /+ code 2 +/
    void b() {...};
    /+ code 3 +/
}

Like this:

void foo()
{
    void delegate() a;
    void delegate() b;

    /+ code 1 +/
    a = () {...};
    /+ code 2 +/

    b = () {...};
    /+ code 3 +/

    // Except that, naturally, a and b cannot
    // be re-assigned by the programmer,
    // and foo itself cannot access a or b
    // before the "a = ...;" and "b = ...;" lines
    // respectively.
}

This maybe makes the most sense, because nested funcs and 
anon-funcs-assigned-to-a-variable *are* so very similar anyway. But then 
again, this comes with the downside of "void main() { 
mixin(import("script.d"));  }" causing strange semantics inside 
'script.d'...but I guess such strange semantics in 'script.d' would be the 
case even without any nested funcs involved.

Actually, this might be equivalent to approach "A" above.