Not for the functionality - the only difference is that your compiler cannot tell you that you are doing it wrong while a strict interface can be checked at compile time. But the standardization is there, it's just not explicit - your programm will crash/fail when you don't provide a proper callback that obeys the implicit contract (e.g.: takes 2 arguments, first the value, second the error if any; returns nothing).
In most compiled languages with closures, the parameters are type-checked. In some, the return type is also type checked, but there are typically ways to add type checking to the return type if that's important.
I closely related closures to partial application. But mostly.. closures are anonymous objects tiles, you can create one on the fly as needed without cruft.
Languages which support nested functions usually allow those inner functions to be closures.
Closures are easy to implement in garbage-collected languages, but get complicated in non-garbage collected languages. When an inner function normally references variables in an outer scope, they're just references to the stack. But if there's a closure that can outlive the outer scope, those variables have to be saved somewhere.
With C++11 closures, you have to specify what you want to keep around and how you want it kept.[1] Internally, C++11 creates an object to store the variables you want to keep around. This can potentially create lifetime problems, because you can save a reference to a variable, then keep the closure object around longer than the variable being referenced. This creates a dangling pointer. Rust has lifetime checking to catch such errors, but C++11 does not. See this Stack Overflow discussion of how not to shoot yourself in the foot with C++11 closure lifetime undefined behavior.[2]
That's why it's useful to realize that closures and lambdas are not the same thing. Lambdas are simple. Closures are complicated.
[1] http://www.cprogramming.com/c++11/c++11-lambda-closures.html [2] http://stackoverflow.com/questions/27775233/lambdas-and-capt...
[1] See the first example here (which only operates on its arguments but is still referred to as a closure): https://doc.rust-lang.org/book/closures.html
On his first slides, he shows the words, "anonymous functions", "lambdas", "closures", "function values", and "first-class values", and shows how each has subtly different meanings/implications and tends to take us down different lines of thinking which affects the conversation you are trying to have with somebody else.
"A closure with an empty environment" vs "a lambda" is a fine, barely-existent line. Or arguably identical.
> A lambda can close over state or not, it doesn't matter.
I've never heard of any definition of "function" that allows closing over state, that's the demarcation that we use to distinguish a function from a closure. What taxonomy are you trying to propose? And going back to my original question, what is the practical intent of trying to make a lambda a semantically-distinct concept from a closure?
Maybe I'll write a blog post.
Ie
function f(...) {...}
g(f);
(This is a genuine terminology question, not an exercise in pedantry.)
In Javascript and Python, all functions passed as parameters to other functions are potentially closures, but this is not the case in most compiled languages.
[1] http://umich.edu/~eecs381/handouts/Pointers_to_memberfuncs.p...
The closure need to be created explicitly with something like std::bind or an actual lambda, and passed around as an std::function (a type erased, generic closure wrapper) or as a template parameter.
/pedantic
[1] GCC does have a very old extension that actually creates the closure.