Nested functions should be exempt from sequential visibility rules

Don Clugston dac at nospam.com
Tue Apr 3 05:06:35 PDT 2012


On 03/04/12 13:51, Nick Sabalausky wrote:
> "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.

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.


More information about the Digitalmars-d mailing list