I think you should read my article ;-) ... because the point is that nested functions in C are basically implemented in a very similar way as C++'s lambdas with "unnameable types" a frontend detail.
The idea that "closures ... have taken over nested functions in language design and thus it isn't really applicable for modern languages." is true only if you think C++ as basically the only modern language and everything else with nested functions is not modern, which is ... an interesting take.
I am confused why you cite these languages as an example to your claim that closures are preferred over nested functions in language design (which is already a confusing statement), as many of them do have nested functions, e.g. Go, Julia, C#, Javascript, Nim. Rust has at least limited "non-capturing" nested functions as far as I know.
Comments
I think you should read my article ;-) ... because the point is that nested functions in C are basically implemented in a very similar way as C++'s lambdas with "unnameable types" a frontend detail.
The idea that "closures ... have taken over nested functions in language design and thus it isn't really applicable for modern languages." is true only if you think C++ as basically the only modern language and everything else with nested functions is not modern, which is ... an interesting take.
C++, C#, Java, JavaScript, Rust, Go, Julia, Nim, Zig.
I'm shocked that you didn't even pick up Rust, given how frequently I mention it on the WG14 reflector.
I am confused why you cite these languages as an example to your claim that closures are preferred over nested functions in language design (which is already a confusing statement), as many of them do have nested functions, e.g. Go, Julia, C#, Javascript, Nim. Rust has at least limited "non-capturing" nested functions as far as I know.