there is a simple answer for this. Closures may catch other variables in the environment they were created in, so they always consist of two pointers, one pointing to the function, one two an object holding the environment.
If you really want to mess with raw function pointers, consider using these procs: https://nim-lang.org/docs/system.html#rawProc%2CT https://nim-lang.org/docs/system.html#rawEnv%2CT
import system
proc testCallback(arg: int): proc() {.closure, gcsafe, locks: 0.} =
result = proc() {.closure, gcsafe, locks: 0.} = echo "res", arg
var p1 = testCallback(5)
var p1Pointer = system.rawProc(po1)
?? How to cast back cast[proc() {.closure, gcsafe, locks: 0.}](p1Pointer)()here we go: https://play.nim-lang.org/#ix=22rS
but with all seriousness tell me where you need this, because this code exploiting internal compiler behaviour is just terrible in any imaginable way! I am quite sure there will be a safer and more idiomatic way than doing it like this.
I think the reason rawProc and rawEnv exist but no mechanism the other way around is that it can be useful for interfacing c code. Often c libraries have "context" pointers for their callbacks, which this way can be used to use Nim closures. Note that when doing it one would still have to keep an eye open on the env memory not being GCed.
Also it's not necessary for you to create separate thread for this directly related question, if it does anything it confuses people, because this thread already lacks a ton of context.
Thank you very much. Yes, I need to call this function from C.
For example, I need to add a callback function to the button of the UI system. The UI system is a c library. I will first store the pointers to rawProc and rawEnv and release them when they are not needed.