void function() fp;
    extern(Windows) int func()
    {
        static int otherfunc()
        { return 0; }

        fp = &otherfunc;
        return fp();
    }

This code won't work since function otherfunc is extern(Windows).
I have no way to declare it extern(D). I can't even write the word
'extern' inside a function body.
I think that nested functions shouldn't follow their enclosing function
calling convention. They should be extern(D) by default.
And we should be able to specify the convention to use with the
'extern' keyword also inside other functions' body (both for functions
and for function pointers).

I also noticed that we have to write the nested function before using it. I think this is incongruous with the general rule: D must care not where a function is written, but only if it's written in the correct scope. The same rule should apply to imports. (Actually the import statement must precede the code that uses the imported symbols.)

I'd also like very much to be allowed to import a module in a function,
see the example:
int main()
{
    import ctype;
    return isalpha("5");
}
I remember I already asked for this feature but it was rejected.
I don't remeber why...

"Dario" <supdar@yahoo.com> wrote in message news:b9th87$1aop$1@digitaldaemon.com...
>     void function() fp;
>     extern(Windows) int func()
>     {
>         static int otherfunc()
>         { return 0; }
>
>         fp = &otherfunc;
>         return fp();
>     }
>
> This code won't work since function otherfunc is extern(Windows).
> I have no way to declare it extern(D). I can't even write the word
> 'extern' inside a function body.
> I think that nested functions shouldn't follow their enclosing function
> calling convention. They should be extern(D) by default.

You're right.

> And we should be able to specify the convention to use with the 'extern' keyword also inside other functions' body (both for functions and for function pointers).

I'm less sure of that. The reason to specify the calling conventions is to be compatible with non-D functions. Nested functions are always D functions.


> I also noticed that we have to write the nested function before using it.

That's true of all declarations within a function.

> I think this is incongruous with the general rule: D must care not where a function is written, but only if it's written in the correct scope.

I think you're right, but it's a significant impact on the semantic analyzer.

> The same rule should apply to imports. (Actually the import statement must precede the code that uses the imported symbols.)
>
> I'd also like very much to be allowed to import a module in a function,
> see the example:
> int main()
> {
>     import ctype;
>     return isalpha("5");
> }
> I remember I already asked for this feature but it was rejected.
> I don't remeber why...

I don't remember why, either <g>.

What is so hard about allowing extern declarators wherever an interface declaration is allowed?  Why must there be a special case?  At least allow us to specify an extern type if we wish to.  Defaulting to D linkage is good in that case.  But the ability to override seems necessary.

What is this semantic problem?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b9v4uu$1gq$2@digitaldaemon.com...
>
> "Dario" <supdar@yahoo.com> wrote in message news:b9th87$1aop$1@digitaldaemon.com...
> >     void function() fp;
> >     extern(Windows) int func()
> >     {
> >         static int otherfunc()
> >         { return 0; }
> >
> >         fp = &otherfunc;
> >         return fp();
> >     }
> >
> > This code won't work since function otherfunc is extern(Windows).
> > I have no way to declare it extern(D). I can't even write the word
> > 'extern' inside a function body.
> > I think that nested functions shouldn't follow their enclosing function
> > calling convention. They should be extern(D) by default.
>
> You're right.
>
> > And we should be able to specify the convention to use with the 'extern' keyword also inside other functions' body (both for functions and for function pointers).
>
> I'm less sure of that. The reason to specify the calling conventions is to be compatible with non-D functions. Nested functions are always D
functions.
>
>
> > I also noticed that we have to write the nested function before using
it.
>
> That's true of all declarations within a function.
>
> > I think this is incongruous with the general rule: D must care not where a function is written, but only if it's written in the correct scope.
>
> I think you're right, but it's a significant impact on the semantic analyzer.
>
> > The same rule should apply to imports. (Actually the import statement must precede the code that uses the imported symbols.)
> >
> > I'd also like very much to be allowed to import a module in a function,
> > see the example:
> > int main()
> > {
> >     import ctype;
> >     return isalpha("5");
> > }
> > I remember I already asked for this feature but it was rejected.
> > I don't remeber why...
>
> I don't remember why, either <g>.

> > And we should be able to specify the convention to use with the 'extern' keyword also inside other functions' body (both for functions and for function pointers).
> I'm less sure of that. The reason to specify the calling conventions is to be compatible with non-D functions. Nested functions are always D
functions.

But static nested functions don't have to be D functions.
Moreover, how to write a pointer to a Windows function?
    void func()
    {
        extern(Windows) void function() a;
    }
(this code doesn't compile.)

> > I also noticed that we have to write the nested function before using
it.
> That's true of all declarations within a function.

I agree that data declaration must precede the code that uses it. But I think function declaration shouldn't.

> > I think this is incongruous with the general rule: D must care not where a function is written, but only if it's written in the correct scope.
> I think you're right, but it's a significant impact on the semantic analyzer.

I suspected it. <='(
We can live without it, but it's sometimes boring.

> > The same rule should apply to imports. (Actually the import statement must precede the code that uses the imported symbols.)
> >
> > I'd also like very much to be allowed to import a module in a function,
> > see the example:
> > int main()
> > {
> >     import ctype;
> >     return isalpha("5");
> > }
> > I remember I already asked for this feature but it was rejected.
> > I don't remeber why...
> I don't remember why, either <g>.

I think it was because of the phases of the compilation process.
Or maybe I'm simply misremembering... ;-)
Can it be done?

"Dario" <supdar@yahoo.com> wrote in message news:ba066a$1237$1@digitaldaemon.com...
> > > And we should be able to specify the convention to use with the 'extern' keyword also inside other functions' body (both for functions and for function pointers).
> > I'm less sure of that. The reason to specify the calling conventions is
to
> > be compatible with non-D functions. Nested functions are always D
> functions.
> But static nested functions don't have to be D functions.
> Moreover, how to write a pointer to a Windows function?
>     void func()
>     {
>         extern(Windows) void function() a;
>     }
> (this code doesn't compile.)

Since Windows has no concept of nested D functions, it can't set up the frame properly for it. Nested functions are not supported by C, and so cannot be supported by external C code.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9v8el$4m3$1@digitaldaemon.com...
> What is so hard about allowing extern declarators wherever an interface declaration is allowed?  Why must there be a special case?  At least allow us to specify an extern type if we wish to.  Defaulting to D linkage is
good
> in that case.  But the ability to override seems necessary.

Why is it necessary? The only purpose for the extern is to interface with functions written in other languages. Those languages do not support calling nested functions.

> What is this semantic problem?

Function semantic processing is done in one pass, whereas the global is done in 3 passes.

> > Moreover, how to write a pointer to a Windows function?
> >     void func()
> >     {
> >         extern(Windows) void function() a;
> >     }
> > (this code doesn't compile.)

> Since Windows has no concept of nested D functions, it can't set up the frame properly for it. Nested functions are not supported by C, and so cannot be supported by external C code.

Consider this code:
    void createwndclass()
    {
        extern(Windows) static int wndproc(HWND w, int m, WPARAM w, LPARAM
l)
        {
            switch(m) {...}
        }

        WNDCLASS wndclass = { lpfnWndProc: &wndproc, ... };
        RegisterClass(&wndclass);
    }
Shouldn't this be correct? Why shouldn't a static nested function be
extern(Windows)?

> > I also noticed that we have to write the nested function before using
it.
> > I think this is incongruous with the general rule: D must care not where a function is written, but only if it's written in the correct scope.

> I think you're right, but it's a significant impact on the semantic analyzer.

I found out that this restriction prevents two nested functions call one
another.
    void func()
    {
        void one()
        {
            two(); // error: two is not declared yet
        }
        void two()
        {
            one(); // ok
        }
    }
So the work-around of moving the nested functions before they're used
does not always work.

> Why is it necessary? The only purpose for the extern is to interface with functions written in other languages. Those languages do not support
calling
> nested functions.
>

What about the ability to pass nested functions as callbacks to other functions. This is a C++ function I wrote that is effectively GetDlgItem() for n-level children

HWND FindChildById(HWND hwndParent, int const id)
{
  if(::GetDlgCtrlID(hwndParent) == id)
  {
    return hwndParent;
  }
  else
  {
    class ChildFind
    {
    public:
      explicit ChildFind(HWND hwndParent, int const id)
        : m_hwndChild(NULL)
        , m_id(id)
      {
        ::EnumChildWindows( hwndParent,
                            EnumProc,
                            reinterpret_cast<LPARAM>(this));
      }

    public:
      operator HWND() const
      {
        return m_hwndChild;
      }

    private:
      static BOOL CALLBACK EnumProc(HWND hwnd, LPARAM lParam)
      {
        ChildFind &find = *reinterpret_cast<ChildFind*>(lParam);

        return (::GetDlgCtrlID(hwnd) == find.m_id)
                  ? (find.m_hwndChild = hwnd, FALSE)
                  : TRUE;
      }

    private:
      HWND      m_hwndChild;
      int const m_id;

    } find(hwndParent, id);

    return find;
  }
}

It uses a nested class in order to get the callback. It would be very nice to be able to do similar things with nested functions, no? The D implementation could be something like

HWND FindChildById(HWND hwndParent, int id)
{
    if(GetDlgCtrlID(hwndParent) == id)
    {
        return hwndParent;
    }
    else
    {
        class ChildFind
        {
            HWND        hwndChild;
            int const   id;
        };

        ChildFind   cf;

        cf.hwndChild    =   NULL;
        cf.id           =   id;

        extern(Windows) BOOL FindChildProc(HWND hwnd, LPARAM lParam)
        {
            ChildFind find = *reinterpret_cast<ChildFind*>(lParam);

            return (GetDlgCtrlID(hwnd) == find.m_id)
                        ? (find.m_hwndChild = hwnd, FALSE)
                        : TRUE;
        }

        ::EnumChildWindows(hwndParent, FindChildProc,
reinterpret_cast<LPARAM>(&cf));

        return cf.hwndChild;
    }
}

which is even more succinct.

(btw, this is not compiled, so may not be syntactically correct)

It would be nice, but Windows doesn't know how to call nested functions. If you're using it with other D functions, there's no need to give it a Windows calling convention.