为什么这个闭包需要内联或“dyn”？ `dyn` 在这里做什么？

我对下面的生命周期发生了什么感到困惑：

struct Foo{}
impl Foo {
    fn foo(&self, _s: &str) {}
}

fn main() {
    let foo = &Foo{};
    let closure = |s| foo.foo(s);

    // Part 1: error message about wrong lifetime in FnOnce
    take_closure(closure); 

    // Part 2: no error when inlined
    take_closure(|s| foo.foo(s));

    // Part 3: no error when `dyn`d and given explicit signature
    let closure: &dyn Fn(&str) -> _ = &|s| foo.foo(s);
    take_closure(closure);
}

fn take_closure(f: impl Fn(&str) -> ()) {
    let s = get_string();
    f(&s)
}

fn get_string() -> String {
    "".to_string()
}

操场

1. 为什么第 1 部分会出错？
2. 为什么第 2 部分没有错误？
3. 为什么第 3 部分没有出错？第 3 部分实际发生了什么？ Rust 会创建 vtable 吗？ LLVM 输出的差异为 2 和 3
4. 有没有更好的办法？内联很丑陋并且dyn既丑陋又让我想知道它到底做了什么。

为什么第 1 部分会出错？

当闭包与它的使用位置分开声明时，Rust 的类型推断不能很好地决定闭包应该具有什么类型。当闭包接受引用时，编译器通常会假设存在一些specific将涉及的生命周期，而不是此处实际需要的“调用者关心提供的任何生命周期”。

事实上，有一个活跃的 Rust RFC 来改善这一点通过添加另一种方法来指定闭包的生命周期参数。 （RFC 还包含一个示例，其中做出相反的寿命假设是行不通的。）

第 3 部分到底发生了什么？ Rust 会创建 vtable 吗？

是的，每当你使用时都会涉及到一个vtabledyn。这与这里的根本原因并不是特别相关；只是被忽略的生命周期dyn Fn(&str)以您需要的方式而不是您不需要的方式解决。

有没有更好的办法？内联很丑陋并且dyn既丑陋又让我想知道它到底做了什么。

将闭包直接放置在使用它的函数调用表达式中是very常见的 Rust 风格，我建议您尽可能坚持使用它，因为它也是与类型推断配合良好的方式。

作为需要多次使用闭包的情况下的解决方法，您可以通过限制其类型的函数传递闭包：

fn string_acceptor<F: Fn(&str) -> ()>(f: F) -> F {
    f
}

...

    let foo = &Foo{};
    let closure = string_acceptor(|s| foo.foo(s));