The parameter type `T` may not live long enough

Question

I'm trying to write a small program in Rust but I can't get it work.

I have reproduced the error in a smaller script:

fn main() {
    let name = String::from("World");
    let test = simple(name);
    println!("Hello {}!", test())
}

fn simple<T>(a: T) -> Box<Fn() -> T> {
    Box::new(move || -> T {
        a
    })
}

When I compile it, I get this error:

error[E0310]: the parameter type `T` may not live long enough
  --> test.rs:8:9
   |
7  |       fn simple<T>(a: T) -> Box<Fn() -> T> {
   |                 - help: consider adding an explicit lifetime bound `T: 'static`...
8  | /         Box::new(move || -> T {
9  | |             a
10 | |         })
   | |__________^
   |
note: ...so that the type `[[email protected]:8:18: 10:10 a:T]` will meet its required lifetime bounds
  --> test.rs:8:9
   |
8  | /         Box::new(move || -> T {
9  | |             a
10 | |         })
   | |__________^

I have tried to add an explicit lifetime bound T: 'static as suggested by the error but I get a new error:

error[E0507]: cannot move out of captured outer variable in an `Fn` closure
 --> test.rs:9:13
  |
7 |     fn simple<T: 'static>(a: T) -> Box<Fn() -> T> {
  |                           - captured outer variable
8 |         Box::new(move || -> T {
9 |             a
  |             ^ cannot move out of captured outer variable in an `Fn` closure

Answer 1

There's a couple of things going on here, and it all has to do with a slight awkwardness around move semantics and closures.

First off, the simple function does need to specify a lifetime for its T parameter. From the function's point of view, T can be any type, which means it could be a reference, so it needs to have a lifetime. Lifetime elision doesn't apply to this case so you need to write it out explicitly. The compiler suggests 'static, which is fine for a hello world. If you had more complex lifetimes, you'd need to use a lifetime parameter; see my example below for more.

Your closure can't be a Fn, because you can't call it more than once. As the new error you've got says, your closure moves the value it captures (a) out of the closure when it's called. That's the same thing as saying it's a method that takes self instead of &self. If function calls were a normal method instead of having special syntax, it would be something like this:

trait FnOnce {
    type Output
    fn call(self) -> Output
}

trait Fn : FnOnce {
    fn call(&self) -> Output
}

// generated type
struct MyClosure<T> {
    a: T
}

impl<T> FnOnce for MyClosure<T> {
    fn call(self) -> T { self.a }
}

(This is not that much simpler than the actual definitions of these types.)

So in short, a closure that consumes its captured values doesn't implement Fn, only FnOnce. Calling it consumes the closure. There's also a FnMut but that's not relevant here.

This has another implication, to do with consuming values when they're moved. You might have noticed that you can't call a method that takes self on any trait object (Box<T> where T is a trait). To move an object, the code that's moving it needs to know the size of the object being moved. This doesn't happen with trait objects, which are unsized. That also applies to Box<FnOnce>. Since calling the closure moves it (because calling is a self method`), you can't call the closure.

So how to get around this problem? It makes Box<FnOnce> a bit useless. There's two options.

If you can use unstable Rust, you can use the FnBox type: it's a replacement for FnOnce that works inside a Box. It's hidden behind a feature gate because, as the documentation warns you: "Note that FnBox may be deprecated in the future if Box<FnOnce()> closures become directly usable." Here's a playground that uses this solution and adds lifetime parameters to fix the original problem.

An alternative that might be a more broadly applicable engineering solution would be to avoid moving out of the closure.

• You could return a reference &'static T if you're always putting static objects into the closure. That way you can call the closure as many times as you like and all callers get a reference to the same object.

• If the object isn't static, you could instead return a Rc<T>. In this case, all callers still get a reference to the same object, and the lifetime of that object is dynamically managed, so it'll stay alive as long as needed. Here's another playground implementing this option.

• You could have the closure copy its argument to each caller. This way it could be called as many times as necessary and each caller would get its own copy. No further lifetime management would be necessary. If you implement it this way, you can still make the argument an Rc<T> instead of a T to use the function the same way as the option above.