Nested functions should be exempt from sequential visibility rules

[Don Clugston]

On 03/04/12 12:32, Timon Gehr wrote:
> On 04/03/2012 10:27 AM, Don Clugston wrote:
>> On 03/04/12 07:38, Nick Sabalausky wrote:
>>> Regarding this:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=790
>>>
>>> I submit that nested functions should be exempt from the usual
>>> sequential
>>> visibility rules. (Therefore, mutually recursive nested functions would
>>> become possible.)
>>>
>>> Or at the very *least*, this horrific C-like workaround should be
>>> possible:
>>>
>>> void foo()
>>> {
>>> void b();
>>> void a() {...};
>>> void b() {...};
>>> }
>>>
>>> ...Flame away! ;)
>>>
>>
>> This is asking for a complicated special case. In global scope, order of
>> declarations doesn't matter. In function scope, order of declarations
>> always matters.
>> 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.
>
> I come to a different conclusion. If only function declarations are
> immune to ordering rules, the above example is simply illegal. The
> example cannot be used to demonstrate incompleteness of the approach.

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.