Good points, all.

I think I misliked Pascal's nested procedures because they weren't true lambdas; once the outer procedure returned, the inner procs were no longer callable (just one contiguous stack, right?). Early-on, using C++ lambdas, I found myself making the same mistake in a design for some asynchronous completion stuff. Embarrassing; C++ and Pascal are not JavaScript/Lisp/Scheme/Smalltalk :-)

You can assign a c++ lambda into an object for later use, you just have to be careful about capture by reference and capturing pointer types... But the capture using the copy constructor is handy here, eg. you can copy a shared_ptr and get reference counted captures...

It's funny in this way how c++ lambdas lead to very c++ specific issues and uniquely c++-ish solutions. I think the wackiness of the closure capture mechanism is the best example of this I can think of.

Misliked?

Mind blowing factoid: not everybody on the internet is a native english speaker.

Not sure what your point is, but it's a real word :-)

Off-topic, but nested functions are one of my favorite gcc extensions.

I discovered with C and C++ compilers, if an extension was added that was not in the Standard, nobody would use it - not even the people who requested the extension. It wasn't like the Pascal community, where nobody would use the compiler unless it had a boatload of extensions :-)

They tried to fix that with ISO Extended Pascal, but by then compatibility with Turbo Pascal extensions was more relevant.

I think you're onto something (about C extensions). There was a time, before clang became default on osx, when Apple deprecated nested functions (and perhaps others) in their version of gcc, and afaik no one complained. So I may well be one of the very few. Oh well.

In the past I've sometimes used standard C++ local structs to nest functions. E.g.:

    int f()
    {
        struct local {
            static int nested_func()
            {
                return 123;
            }
        };

        return local::nested_func();
    }

I've done that, too. It's clumsy and only does half the job (doesn't provide access to locals). At some point one just gets tired of the workarounds :-)

It's probably a bit late for this reply, but... Another clumsy workaround is to use operator(). Again, standard C++ and this one has access to local variables:

    int g()
    {
        int x, y;

        struct local {
            int & a_;
            int & b_;
            local(int & a, int & b) : a_(a), b_(b) {}
        
            int operator()()
            {
                return a_ + b_;
            }

        } nested(x, y);

        x = 99; y = 1;
        return nested();
    }

    assert(g() == 100);

Nested functions are good if you have no alternative. If you use them as lambdas or a means of code folding, (both of which don't exist in older IDEs and compilers) you will have to keep jumping around in code in order to follow the logic. That is a very tiring thing to do, especially if you just switched jobs.

There are always alternatives. The issue is how naughty or nice they are.

>3. A lot of my need for goto statements vanished with nested functions.

How does that work? Not immediately obvious to me.

A lot of the goto's were used to use a common sequence of code followed by a return. With nested functions, the nested function contains the common sequence of code, and you just:

    T common() { ...common sequence of code... }
    ...
    return common();

instead of:

    goto Lcommon;
    ...
    Lcommon:
    ... common sequence of code ...
    return result;

Got it now, thanks. But, this (the "return common();") could be done even if the function "common" was not nested within the current function, but defined outside of it, right? So what is the benefit of defining "common" as a nested function? Is it because it then has access to, and can use, variables defined in the outer function?

Yes, you can do it that way. But then you'll need a "context pointer" to pass references to the locals it'll need, and the function will need to be located "someplace else", meaning it is not encapsulated.

I've done that for years with C and C++. Nested functions are so much nicer and clearer.

Got it now, thanks. I've used nested functions in Python and they have some good uses. Will check them out in D.

C# has just implemented nested functions.

There is a nice blog post that concisely explains why local functions are better than lambdas: https://asizikov.github.io/2016/04/15/thoughts-on-local-func...

C#: "Local functions can not be static."

Static nested (i.e. local) functions in D can be static. What that does is prevent the function for accessing locals in the enclosing scope(s).

> nested functions in Pascal and D

Or just have first class functions, and prototype based inheritance. Way more flexible and powerful than class based inheritance. See JavaScript 5 as an example, ask Crockford.