Forward declaration inside Function block, no error?

Steven Schveighoffer schveiguy at
Mon Jan 7 19:48:06 UTC 2019

On 1/7/19 12:20 AM, Jonathan M Davis wrote:
> On Sunday, January 6, 2019 11:38:44 AM MST Benjamin Thaut via Digitalmars-d-
> learn wrote:
>> Today I found a bug in my D code.
>> import std.stdio;
>> // Type your code here, or load an example.
>> void grow()
>> {
>>       writeln("grow");
>> }
>> void someFunc(bool condition)
>> {
>>       if(condition)
>>       {
>>           void grow();
>>       }
>> }
>> I tried to call the grow function, but accidentially copied the
>> return value alongside the function name. I was wondering why
>> this code compiles without errors. the "void grow();" becomes a
>> no-op. In my opinion this could should not compile. Am I missing
>> something here?
> It would actually be useful if you could provide prototypes for extern(C)
> functions that way (similar to how we can have local imports for modules and
> thus avoid affecting the rest of the module), but unfortunately, that
> doesn't currently work (even if the function declaration is marked with
> static). It would also make sense if it allowed you to provide forward
> declarations for nested functions, but that doesn't work either. So, I could
> see uses cases where it would theoretically be useful to be able to declare
> function prototypes inside of a function, but as it stands, AFAIK, it's
> useless. It is arguably a case of "turtles all the way down," but since you
> can't then do anything useful with the function prototype, it's currently
> pretty pointless.

One could use it as a strawman, that's never called, but used for 

I tried to use pragma(mangle), but it doesn't seem to work on inner 
functions (weird).

If I declare the pragma(mangle) outside the function, it works, but that 
doesn't help if the function actually needs the outer function context 
to operate.

Allowing forward declarations for nested functions would be nice.


More information about the Digitalmars-d-learn mailing list