Warning
Info
I'm working on function hooking library (mainly for native game modding) that builds on my closure-ffi crate to allow capturing closures to be used as hooks. At the moment I'm just trying out different user-facing APIs for constructing the hook, to see what plays nicely with type inference.
One thing that is very useful to be able to do when writing hooks is to access a function pointer to that calls the original function (usually via a JIT'd trampoline) from within the hook body itself. I attempted to do this by having the user provide a "getter" FnOnce impl that is passed the hook context, and returns their hook closure. This way they can move it into their hook body.
I particularly like this solution because it doesn't require further macro-implementing traits for functions of different argument counts in the hooking crate (beyond what is already done in closure-ffi). However, this plays very poorly with type inference as can be showed in the example below (cut down to only the necessary parts to show the problem).
What's particularly surprising to me is that case 4 in the above code type infers successfully, but 5 doesn't. Yet both require knowing the generic parameters of ctx to some extent (for the cast to be valid in case 4 and the function pointer call in case 5).
Is there a general "rule" of how closure type inference works that prevents cases 5 and 6 from working no matter what, and does anyone know if the API or trait definitions could be modified to allow the same thing to be done, while allowing the failing cases to type infer successfully?
1 post - 1 participant
🏷️ rust_feed