It's straight from C++ which has had them since 2011.

I recently wrote some paper: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3654.pdf which also includes a short summary of issues when trying to put C++'s lambdas into C.

You can also have some kind of heapify/free, with undefined behavior if you get it wrong.

I think the C standards committee needs to figure out memory safety before adding any new features that are likely to interact with it.

     void
     mkclosure(int x)
     {
         int x;
         void fn(void){ return x + 1; }
         return fnheapify(fn);
     }

     void
     useclosure(void)
     {
         void (^fn)(void) = mkclosure(42);
         fn();
         fnfree(fn);
     }

If you want them only to "escape" down the stack then it's not necessary. If you want them to escape up the stack then of course you can't have them capture a pointer to the stack variable, because that will no longer exist once the current function returns. However if you capture all variables by value and make the lambda an unique type containing all the captured variables then you can return it up the stack. Of course the downside of this is that each lambda gets its own different type, but you can add ways to convert them to a common type at the cost of having to then deal with the allocation issue at that point.