On 10/15/2012 08:14 AM, Niko Matsakis wrote:
(Note: we somehow lost the rust-dev cc, see Stefan's e-mail below)
Under the plan as I envisioned it in my head, ignoring the question
about unsafety, it would be necessary to write a wrapper for a C
function if you wanted it to have the same type as a Rust fn (as opposed
to an `extern "C" fn()` type). However, I could imagine permitting
extern fn items to be coerced to Rust type, and having the compiler
auto-generate a wrapper. We plan to do something similar with top-level
Rust fns: they will be coercable to a C function type, so that any Rust
fn item can used as a callback, and not just an "extern fn". However,
this of course immediately raises the question of unsafety: we could
presumably want a way to declare that those C functions are safe as well.
Another option is just to use a macro, of course. Or that would be an
option if we supported item-level macros, which we hopefully will soon.
The question I guess is how often this situation comes up. Is it just
libmath? Or is this sort of thing extremely common when doing bindings?
Personally, I think making c_math do wrappers is not a big deal.
Somewhat OT: Regarding our new approach of generating the wrappers on
demand, I think that this is fine, but also that someday we probably
will want to be able to call cdecl Rust functions directly from native
code, without a stack switch. JS wants to call in to Rust as fast as
technically possible and that may eventually mean getting rid of the
extra function pointer.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
