I'm ok with this working.. But I'm not sure why it can work?
From a fundamental level a proc is just a pointer to a procedure which accepts variables. Very straight forward. I've been comfortable with doing polymorphics to build up the exact proc signature.
But this is fine and I'm not sure why it's fine considering normally casting things is such a big deal? Or is it only a big deal for types other than procedures?
What I'm worried about is how this could break in ways I don't immediately see.
https://github.com/Ferinzz/ProcAnyProc
#ProcAnyProc?? Can it really be this easy? (and unsafe)
lean forum
unkempt heath
All pointers are implicitly convertible to rawptr so that's the risk you're taking on.
Other than that, this appears to be an incomplete example of how you'd invoke functions with a slice of arguments, using the proc's type to check each argument type and return type.
The proc must be a compile-time constant for this info to be present, note that not all procs are.
What do you want this for?
lean forum
I was looking at that bevy schedule thing someone else was looking at a while ago. I was adapting what i did for my godot version and stumbled onto the fact that i don't need a proc for every proc if everything is going to be receiving pointers.
unkempt heath
Oh, like a static wrapper proc for each loaded address?
lean forum
It looks incomplete but at least with the 4 testing procs they all get called no problem.
lean forum
One wrapper for each loaded proc was what i did originally, but based on this example i don't actually need that.
unkempt heath
Can you not use foreign?
I guess I'd need more context around what you're doing to see.
lean forum
This particular setup isn't for a foreign lib. I want to setup a schedule. The schedule will need to receive procs of any and all formats. It will then need to be able to call any of the procs it receives when the time comes.
Problem one: each proc is a unique type. That i know of there is no way to store them in a generic container.
Solution? Use any.
Problem two: you cannot call a proc straight from a raw pointer. You must cast it to a proc type. If you don't cast it to the correct proc type the compiler will complain. Enter polymorphics based on the proc. (I have this working for a different thing it's fine)
Problem three: how will this work with a any type?
Those we're the problems i was trying to solve when i stumbled onto this.
In this example i have a polymorphic that creates a proc based on the proc parameter.
The type it creates doesn't have any type which can be validated when called.
Although this was created in order to call breaker, when a different proc is sent it is able to call that proc 'correctly'. Provided the arguments are all pointers and less than or equal to the number of arguments breaker has.
If i took it out of the polymorphic wrapper the compiler would complain. Because none of the types casting is actually correct.
So it's a hack.
past epoch
hello, check this: #odin-memes message, you may find it interesting. It's a similar concept of what you've done. You'll want to wrap the procedure and call it separately, not not like what I did, which I thought it was a bit of a joke. This method allows for any procedure signature, it doesn't require the parameters to be pointers, etc. I don't know if it's what you want, or you want it to be runtime instead of comptime