Closures are allowed to reference data that may be dropped before the closure itself is dropped currently. This will result in undefined behavior.

This can't be meaningfully prevented in C++, but we aren't even preventing this in Rust.

Due to technical limitations in the C preprocessor this only supports 16 arguments. I suspect 16 is plenty, but I'd someday like to remove this limit. In the short term, the limit can also be raised by providing more macro definitions.

The current technique is very imprecise and likely to come up with false positives. We need a way to either filter out those false positives, or avoid generating them in the first place.

I feel it's healthy for a sub 1.0 project to have a defined list of things that need to happen before it can go 1.0. So here's the list for this repository.

• Figure out a general way to permit multiple arguments to closures that doesn't significantly hamper performance. (Bonus points if it reduces the amount of boxing in this crate)
• Type check arguments on C/C++ side without significantly hampering performance.
  • Provide some kind of compile time mapping between C/C++ classes/structs and Rust structs, then use this mapping to validate call sites (or to generate a type checked function signature). Not necessary, rust bindgen handles this well enough.

There's a general theme here. We need to start doing C/C++ code generation in addition to Rust code generation. Maybe the template system would be useful here? There's a massive amount of ways to do C/C++ builds, and ideally said code generation system would be able to plug into all of them.

The return type is known at compile time, so the destructor doesn't necessarily need to be stored in the closure structure. It could be compiled in to the return type release function.

Trouble is that this would require C to call Rust not via a function pointer, and for this project that would create a circular dependency. Maybe we'll come up with a way to resolve this at some point?

Easy fix since it only needs to be done for the void return macro. Just needs to be done.

It's all code generation now, no need for a runtime crate.