Sure, unless your value objects contain references. Then you’re looking at a deep copy, which can be expensive and/or very application-specific. It’s hard to do copy by value generically.

References in C are implemented by pointers, which can be copied very easily. The trouble is with properly cleaning up when the closure isn't needed anymore, but that problem already exists when you copy pointers explicitly.

You can copy the pointers, but that doesn't make it safe because you could have pointers to stack values.

I don't see how that's relevant. If a developer sets a pointer to point to a stack object then copying the pointer, whether manually or through a hypothetical closure, doesn't change nor create the problem.

The problem is returning a closure that points to a stack variable that's now out of scope.

It isn't. The hypothetical problem was setting a pointer to a stack variable. That's a no-no from the start, and adding hypothetical closures to the mix changes nothing.

Having a pointer to a stack variable is fine, as long as the stack variable lives longer than the closure.

Right, so your original claim about properly cleaning up is not the only problem with closures in C. There are quite a few hazards actually.

> Right, so your original claim about properly cleaning up is not the only problem with closures in C.

Your comment makes no sense. OP stated that your hypothetical problem isn't even a problem if the developer knows what he is doing, and your take from that is that there are more problems?

The original poster said the trouble was cleaning up after the closure is no longer needed. That's clearly not the case as this thread has covered. I thought the previous poster was the original poster, so just replace "your original claim" with "the original claim".

It's C. I assume the programmer would just be responsible for dealing with dangling pointers and double frees.

... and there's ample evidence that this is a reasonable assumption, so let's do closures based on it, too! :)

> ... and there's ample evidence that this is a reasonable assumption

Actually, there is. C might be a colossal footgun but reasonably experienced developers do manage to avoid those problems.

I'd like to see that ample evidence. On the contrary, I know even fairly experienced developers who get burned with memory issues in C - and I have never ever heard of even the most junior developer to have any problem with double frees in Java :)

Plus..... even if you could do that, WHY? C is a simple language, close to the "metal". If you want a language that has every-feature-and-their-mother, and can be close to the metal when needed, and can be used to blow both your feet off, just use C++.

Adding functional closures to C is somewhat akin to adding "asm" and "volatile" in Haskell.... even if you could do it, why would you? It just breaks the very essence of the language.

Well, that's what C++ lambdas do. Though C++ has smart pointers to help with lifetime issues.

> Sure, unless your value objects contain references.

As others have already pointed out, C does not have references. It does however have pointers, and pointers are already copied by value.

> Then you’re looking at a deep copy

There is no such thing in standard C. Objects are copied by value, including pointers, and if you want to "deep copy" your custom data structures then you need to implement your custom cloning routines. However, naturally your custom cloning functions wouldn't be used directly to capture any variable.

> which can be expensive and/or very application-specific.

That's hardly specific to C.

> It’s hard to do copy by value generically.

Actually, it isn't. In fact with C it's quite trivial, and perhaps as trivial as it gets. There's no garbage collection thingy, no RAII, no deep copies, no refcounting... nothing. Just plain memcpy() from one object to another. That's it.

if that meets the semantics of what you’re trying to do, great. but often in programming it’s not. the depth of the copy you want depends on what you’re trying to do. copying pointers (or references, or whatever might point to dynamically allocated memory) by value means using a garbage collector or reference counting mechanism, or risk a memory leak.

It's C.

If you think being specific about what you want copied, freeing only when you know it's appropriate, and tracking any metadata around that yourself if a problem, don't work in C.

Get it right or risk a memory leak is the name of the game.

It’s your program. The suggestion was that copy-everything-by-value solves the closure/memory issue with respect to copies. It does not. This is also why C doesn’t have closures. Ships passing in the night...

> It’s your program.

No, it's the C programming language. It has been like that since the 70s, and lots of people have been using it to develop high availability software for decades.

Just because some people never learned its basics nor are familiar with the subject that doesn't mean they have a point.

> The suggestion was that copy-everything-by-value solves the closure/memory issue with respect to copies.

No, that's quite wrong. The suggestion was thay passing objects by value would enable capturing variables without any of the slippery slope nonsense that was pointed out.

> This is also why C doesn’t have closures.

No, that's quite wrong as well. C doesn't have closures because no one bothered to add them, which is the exact same reason why C doesn't have namespaces or generics or any other feature ever. That's it.

C has generics (within the limitations of its type system) since C11.

https://en.cppreference.com/w/c/language/generic