Nested functions should be exempt from sequential visibility rules

Timon Gehr timon.gehr at gmx.ch
Tue Apr 3 03:32:59 PDT 2012


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.

> 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.
>
> In general, allowing forward references inside a function is far, far
> more difficult than in global scope.

If it is constrained enough, it shouldn't be more difficult.

> There are very many more special
> cases. Allowing it in global scope is quite complicated enough.
>

It should be possible to leverage the efforts spent there.

> You can always use a delegate, if you want recursive nested functions.

Templates are superior.



More information about the Digitalmars-d mailing list