You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be incredibly convenient for rust to be able to do the same:
fnfoo(foobar:fn()){// impl}fnbar(){foo(|| {/* do something */});}
A use case would be a static (const) array of function pointers, where dynamic dispatch is not necessary.
Example in current rust (this is a compilable example):
extern{staticmut b:u32;static n:usize;}const a:[&'static Fn();4] = [&|| unsafe{ b = 4},&|| unsafe{ b = 2},&|| unsafe{ b = 3},&|| unsafe{ b = 1},];pubfnmain(){if n < 4{
a[n]();}}
This obviously relies upon dynamic dispatch to a level that rust is unable to optimize away. Ideally it would be possible to use a table of fn()s instead of &'static Fn() and rust would be able to coerce the closures into function pointers because nothing needs to be captured.
Another, possibly more widely-applicable scenario is simply being able to pass a closure into a C function that takes a callback.
What's the status on this? I ask because on the one hand this issue is closed, yet on the other the feature is still gated behind feature(closure_to_fn_coercion).
In C++, you are able to pass a non-capturing lambda as a function pointer, as, for example, a function argument:
It would be incredibly convenient for rust to be able to do the same:
A use case would be a static (const) array of function pointers, where dynamic dispatch is not necessary.
Example in current rust (this is a compilable example):
This obviously relies upon dynamic dispatch to a level that rust is unable to optimize away. Ideally it would be possible to use a table of
fn()
s instead of&'static Fn()
and rust would be able to coerce the closures into function pointers because nothing needs to be captured.Another, possibly more widely-applicable scenario is simply being able to pass a closure into a C function that takes a callback.
See previous discussion at rust-lang/rust#32449.
The text was updated successfully, but these errors were encountered: