Summary

A closure that does not move, borrow, or otherwise access (capture) local variables should be coercible to a function pointer (fn).

Motivation

Currently in Rust, it is impossible to bind anything but a pre-defined function as a function pointer. When dealing with closures, one must either rely upon Rust's type-inference capabilities, or use the Fn trait to abstract for any closure with a certain type signature.

It is not possible to define a function while at the same time binding it to a function pointer.

This is, admittedly, a convenience-motivated feature, but in certain situations the inability to bind code this way creates a significant amount of boilerplate. For example, when attempting to create an array of small, simple, but unique functions, it would be necessary to pre-define each and every function beforehand:

fn inc_0(var: &mut u32) {}
fn inc_1(var: &mut u32) { *var += 1; }
fn inc_2(var: &mut u32) { *var += 2; }
fn inc_3(var: &mut u32) { *var += 3; }

const foo: [fn(&mut u32); 4] = [
  inc_0,
  inc_1,
  inc_2,
  inc_3,
];

This is a trivial example, and one that might not seem too consequential, but the code doubles with every new item added to the array. With a large amount of elements, the duplication begins to seem unwarranted.

A solution, of course, is to use an array of Fn instead of fn:

const foo: [&'static Fn(&mut u32); 4] = [
  &|var: &mut u32| {},
  &|var: &mut u32| *var += 1,
  &|var: &mut u32| *var += 2,
  &|var: &mut u32| *var += 3,
];

And this seems to fix the problem. Unfortunately, however, because we use a reference to the Fn trait, an extra layer of indirection is added when attempting to run foo[n](&mut bar).

Rust must use dynamic dispatch in this situation; a closure with captures is nothing but a struct containing references to captured variables. The code associated with a closure must be able to access those references stored in the struct.

In situations where this function pointer array is particularly hot code, any optimizations would be appreciated. More generally, it is always preferable to avoid unnecessary indirection. And, of course, it is impossible to use this syntax when dealing with FFI.

Aside from code-size nits, anonymous functions are legitimately useful for programmers. In the case of callback-heavy code, for example, it can be impractical to define functions out-of-line, with the requirement of producing confusing (and unnecessary) names for each. In the very first example given, inc_X names were used for the out-of-line functions, but more complicated behavior might not be so easily representable.

Finally, this sort of automatic coercion is simply intuitive to the programmer. In the &Fn example, no variables are captured by the closures, so the theory is that nothing stops the compiler from treating them as anonymous functions.

Detailed design

In C++, non-capturing lambdas (the C++ equivalent of closures) "decay" into function pointers when they do not need to capture any variables. This is used, for example, to pass a lambda into a C function:

void foo(void (*foobar)(void)) {
    // impl
}
void bar() {
    foo([]() { /* do something */ });
}

With this proposal, rust users would be able to do the same:

fn foo(foobar: fn()) {
    // impl
}
fn bar() {
    foo(|| { /* do something */ });
}

Using the examples within "Motivation", the code array would be simplified to no performance detriment:

const foo: [fn(&mut u32); 4] = [
  |var: &mut u32| {},
  |var: &mut u32| *var += 1,
  |var: &mut u32| *var += 2,
  |var: &mut u32| *var += 3,
];

Because there does not exist any item in the language that directly produces a fn type, even fn items must go through the process of reification. To perform the coercion, then, rustc must additionally allow the reification of unsized closures to fn types. The implementation of this is simplified by the fact that closures' capture information is recorded on the type-level.

Note: once explicitly assigned to an Fn trait, the closure can no longer be coerced into fn, even if it has no captures.

let a: &Fn(u32) -> u32 = |foo: u32| { foo + 1 };
let b: fn(u32) -> u32 = *a; // Can't re-coerce

Drawbacks

This proposal could potentially allow Rust users to accidentally constrain their APIs. In the case of a crate, a user returning fn instead of Fn may find that their code compiles at first, but breaks when the user later needs to capture variables:

// The specific syntax is more convenient to use
fn func_specific(&self) -> (fn() -> u32) {
  || return 0
}

fn func_general<'a>(&'a self) -> impl Fn() -> u32 {
  move || return self.field
}

In the above example, the API author could start off with the specific version of the function, and by circumstance later need to capture a variable. The required change from fn to Fn could be a breaking change.

We do expect crate authors to measure their API's flexibility in other areas, however, as when determining whether to take &self or &mut self. Taking a similar situation to the above:

fn func_specific<'a>(&'a self) -> impl Fn() -> u32 {
  move || return self.field
}

fn func_general<'a>(&'a mut self) -> impl FnMut() -> u32 {
  move || { self.field += 1; return self.field; }
}

This aspect is probably outweighed by convenience, simplicity, and the potential for optimization that comes with the proposed changes.

Alternatives

Function literal syntax

With this alternative, Rust users would be able to directly bind a function to a variable, without needing to give the function a name.

let foo = fn() { /* do something */ };
foo();

const foo: [fn(&mut u32); 4] = [
  fn(var: &mut u32) {},
  fn(var: &mut u32) { *var += 1 },
  fn(var: &mut u32) { *var += 2 },
  fn(var: &mut u32) { *var += 3 },
];

This isn't ideal, however, because it would require giving new semantics to fn syntax. Additionally, such syntax would either require explicit return types, or additional reasoning about the literal's return type.

fn(x: bool) { !x }

The above function literal, at first glance, appears to return (). This could be potentially misleading, especially in situations where the literal is bound to a variable with let.

As with all new syntax, this alternative would carry with it a discovery barrier. Closure coercion may be preferred due to its intuitiveness.

Aggressive optimization

This is possibly unrealistic, but an alternative would be to continue encouraging the use of closures with the Fn trait, but use static analysis to determine when the used closure is "trivial" and does not need indirection.

Of course, this would probably significantly complicate the optimization process, and would have the detriment of not being easily verifiable by the programmer without checking the disassembly of their program.

Unresolved questions

Should we generalize this behavior in the future, so that any zero-sized type that implements Fn can be converted into a fn pointer?

7.3 KiB Raw Permalink Blame History