gcc has this feature, it is implemented by constructing a trampoline-style function on the stack. This requires an executable stack, so isn't really a thing any more.

A nested procedure ("function" is a bit misleading in imperative languages) can close over variables in the outer scope, but has to have its own isolated control.

A truly[2] anonymous procedure can also close over control flow:

    fun hasZeros(ints: List<Int>): Boolean {
      ints.forEach {
        if (it == 0) return true // returns from hasZeros
      }
      return false
    }

[1]: https://kotlinlang.org/docs/reference/inline-functions.html

[2]: "truly" in the sense it's never assigned to a name, and is known to not escape its surrounding scope, which is necessary if the compiler is going to allow it to, e.g. do a non-local return.

However, if you just want a more conventional syntax for nested functions, you can almost get what you want by placing a static method inside of a local class, and it's available in older versions of C++ too:

    #include <stdio.h>

    int main() {

        struct foo {
            static void bar() {
                printf("nested\n");
            }
        };

        foo::bar();

        return 0;
    }

auto func = [](...){....}

for nested funcs

There are a few cases where they can make sense, like in the standard library, but most of the time without them your code will be cleaner and you'll never actually run into the case where they pay off.

C++ programmers who dedicate themselves to template metaprogramming are like stunt performers. You see them get on their shiny bikes and flashy costumes, you clinch your fists in a mix of fear and awe when they showcase their skills, but in the end it might be entertaining but it has virtually no real practical use beyond extremely niche applications.

https://en.wikibooks.org/wiki/More_C++_Idioms/Member_Detecto...

Yes, conceptually it's a bit nuts, but the fact that you can do stuff like this makes it unlikely that you'll ever get completely stuck trying to implement something.

I personally love C++ because it's just a giant bag of tools, even if one of those tools is a footgun.

Why would a C++ programmer learn Go? They should learn Rust since it is pretty much a cleaned up, modernized C++.

Do it, it'll make his day.

In theory the higher abstraction of C++ provides for optimization opportunities for a sufficiently smart compiler. I have yet to see such though.

Write the little bits which need to be fast in C and the gross in a sane language mere mortals can read (e.g. no 'most vexing parse').

Modern c++ is a powerful, expressive language. It’s not a “object oriented” language in the fetishistic sense — I don’t write that many classes comparatively. A lot of generic programming and functional algorithms in my case. And I can couple directly to the iron as needed.

Yes there are some unfortunate syntactic issues due to it having evolved from C but that’s how the world works.

There's no avoiding Rust. It's becoming the jQuery of systems programming.

C++ has lost the plot in some respects but you don't, and probably won't ever, end up using all of it. A lot of it is to make it easier to write things like the STL, not your typical end-user program. Learn up to 17, there's some good stuff in there. If someone in an interview gives you some highly complex templatey code snippet to analyse just tell them to go fuck themselves.

Yes, absolutely. I (somewhat recently) did that, and I find modern C++ to be almost like a new language. The "modern" features are very useful and powerful.

Studying everything new is, of course, a much more ambitious goal.

After writing a bunch of Rust, I recently had to learn C++. I've been storing C++ in my brain as "Rust + delta of dubious ideas", which, not to start a flame war, has easily been a better compression algorithm for my brain than storing C++ in isolation.

For example:

- C++, const is part of the type. Clearly wrong.

- Rust, mut is property of variable, or & vs &mut. Correct, but lack of & with mut-polymorphism just causes needless suffering.

- Rust construction: good, Rust destruction: bad

- C++ destruction: bad, basically like Rust's. C++ construction: bad, matches C++ destruction.

(I've been saying for years that drop needs to consume, not borrow the thing to be destroyed, but no uptake :(.)