Nested functions should be exempt from sequential visibility rules

[Don Clugston]

On 03/04/12 11:24, Nick Sabalausky wrote:
> "Don Clugston"<dac at nospam.com>  wrote in message
> news:jlecab$9gh$1 at digitalmars.com...
>>
>> If you have type inference of function returns, things can get nasty:
>>
>> void foo()
>> {
>>       auto b() { return a(); }
>>       X x = whatever;
>>       auto a() { return x; }
>> }
>> Now b actually depends on the declaration of x. So it's not enough to say
>> that only function declarations are immune to ordering rules.
>
> Does being inside a function really make the type deduction any harder (or
> different?) than this?:
>
> auto b() { return a(); }
> enum X x = whatever;
> auto a() { return x; }

Yes, it's different. In the second case, X is entirely determined at 
compile time. If you have multiple declarations, there are no 
user-visible semantics which are order-dependent; the value of the 
expression is independent of its location in the file.

This is not true of declarations inside a scope:

eg,

    static int count = 0;
    int order() { ++count; return count; }

    int x = order();
    int y = order();

    assert(x == 1);
    assert(y == 2);

>> Furthermore, any declaration before x, which calls b(), is using x even
>> though x hasn't been initialized (or even declared) yet. Suddenly all
>> kinds of horrible situations become possible, which could never happen
>> before.
>>
>
> (Don't know if this makes any sence, but I'm throwing it out there...)
>
> Suppose we did the approach I mentioned elsewhere in this thread: "the
> compiler rewrites nested func decls as delegate vars and anon funcs".
> Suppose we also use the rule:
>
> "A nested func is not *callable* (by either the parent function *or* another
> nested function) until after (ie "further down in the code") all the sibling
> symbols it accesses have been declared."

Difficult but doable, but I think you end up with a really funky rule.
It's a morass of special cases.