Closed adam-mcdaniel closed 4 years ago
That looks way better. So this essentially generating typed wrapper functions instead of having to write those yourself right? This does still require the foreign function to know about the oak abi and provide the bridge to its native abi, but that is probably out of scope of the current issue.
If possible, I would like to get rid of explicit foreign function calls. I think the following solution would be more elegant for typechecking.
Instead of using
foreign_func!()
to call a foreign function, I would like to introduce theextern
keyword. It's usage would look like this.Here, if we use the C target, we grab the foreign functions
__oak_memcpy
,__oak_memset
, andprend
and give them Oak type signatures.memcpy
would expand to the following at compile time.This looks much better, and it also abstracts away foreign functions from the user. Lets say you're using a library that uses foreign functions. You could use them without any typechecks just by calling them directly with the
!
operator. With theextern
keyword, though, typechecks are possible.