存储引用该对象中的对象的盒装闭包

Question

I'm trying to implement a console system for the game I'm writing and have found a fairly simple system: I define a Console object that stores commands as boxed closures (specifically Box<FnMut + 'a> for some 'a ). This works for any component of the engine so long as the Console is created before anything else.

Unfortunately, this prevents me from adding commands that modify the Console itself, which means I can't create commands that simply print text or define other variables or commands. I've written a small example that replicates the error:

use std::cell::Cell;

struct Console<'a> {
    cmds: Vec<Box<FnMut() + 'a>>,
}

impl<'a> Console<'a> {
    pub fn println<S>(&self, msg: S)
        where S: AsRef<str>
    {
        println!("{}", msg.as_ref());
    }

    pub fn add_cmd(&mut self, cmd: Box<FnMut() + 'a>) {
        self.cmds.push(cmd);
    }
}

struct Example {
    val: Cell<i32>,
}

fn main() {
    let ex = Example {
        val: Cell::new(0),
    };

    let mut con = Console {
        cmds: Vec::new(),
    };

    // this works
    con.add_cmd(Box::new(|| ex.val.set(5)));

    (con.cmds[0])();

    // this doesn't
    let cmd = Box::new(|| con.println("Hello, world!"));
    con.add_cmd(cmd);

    (con.cmds[1])();
}

And the error:

error: `con` does not live long enough
  --> console.rs:34:31
   |
34 |         let cmd = Box::new(|| con.println("Hello, world!"));
   |                            -- ^^^ does not live long enough
   |                            |
   |                            capture occurs here
35 |         con.add_cmd(cmd);
36 |     }
   |     - borrowed value dropped before borrower
   |
   = note: values in a scope are dropped in the opposite order they are created

error: aborting due to previous error

Is there a workaround for this, or a better system I should look into? This is on rustc 1.18.0-nightly (53f4bc311 2017-04-07) .

Answer 1

This is one of those fairly tricky resource borrowing conundrums that the compiler could not allow. Basically, we have a Console that owns multiple closures, which in turn capture an immutable reference to the same console. This means two constraints:

• Since Console owns the closures, they will live for as long as the console itself, and the inner vector will drop them right after Console is dropped.
• At the same time, each closure must not outlive Console , because otherwise we would end up with dangling references to the console.

It may seem harmless from the fact that the console and respective closures go out of scope at once. However, the drop method follows a strict order here: first the console, then the closures.

Not to mention of course, that if you wish for closures to freely apply modifications to the console without interior mutability , you would have to mutably borrow it, which cannot be done over multiple closures.

An approach to solving the problem is to separate the two: let the console not own the closures, instead having them in a separate registry, and let the closures only borrow the console when calling the closure.

This can be done by passing the console as an argument to the closures and moving the closure vector to another object ( Playground ):

use std::cell::Cell;

struct CommandRegistry<'a> {
    cmds: Vec<Box<Fn(&mut Console) + 'a>>,
}

impl<'a> CommandRegistry<'a> {
    pub fn add_cmd(&mut self, cmd: Box<Fn(&mut Console) + 'a>) {
        self.cmds.push(cmd);
    }
}

struct Console {
}

impl Console {
    pub fn println<S>(&mut self, msg: S)
        where S: AsRef<str>
    {
        println!("{}", msg.as_ref());
    }
}

struct Example {
    val: Cell<i32>,
}

fn main() {
    let ex = Example {
        val: Cell::new(0),
    };

    let mut reg = CommandRegistry{ cmds: Vec::new() };

    let mut con = Console {};

    // this works
    reg.add_cmd(Box::new(|_: &mut Console| ex.val.set(5)));
    (reg.cmds[0])(&mut con);

    // and so does this now!
    let cmd = Box::new(|c: &mut Console| c.println("Hello, world!"));
    reg.add_cmd(cmd);

    (reg.cmds[1])(&mut con);
}

I also took the liberty of making closures accept a mutable reference. No conflicts emerge here because we are no longer borrowing the console that was already borrowed when fetching the borrowing closure. This way, the closures can also outlive the console.