rust - 无法为返回引用的闭包推断适当的生存期

Question

考虑以下代码:

fn foo<'a, T: 'a>(t: T) -> Box<Fn() -> &'a T + 'a> {
    Box::new(move || &t)
}

我的期望:

类型T具有生命周期'a。

值t与T一样长。

t移至闭包，因此闭包的生存时间与t

一样长

该闭包返回对t的引用，该引用已移至该闭包。因此，只要闭包存在，该引用就有效。

没有生命周期问题，代码可以编译。

实际发生的情况:

该代码无法编译:

error[E0495]: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements
 --> src/lib.rs:2:22
  |
2 |     Box::new(move || &t)
  |                      ^^
  |
note: first, the lifetime cannot outlive the lifetime  as defined on the body at 2:14...
 --> src/lib.rs:2:14
  |
2 |     Box::new(move || &t)
  |              ^^^^^^^^^^
note: ...so that closure can access `t`
 --> src/lib.rs:2:22
  |
2 |     Box::new(move || &t)
  |                      ^^
note: but, the lifetime must be valid for the lifetime 'a as defined on the function body at 1:8...
 --> src/lib.rs:1:8
  |
1 | fn foo<'a, T: 'a>(t: T) -> Box<Fn() -> &'a T + 'a> {
  |        ^^
  = note: ...so that the expression is assignable:
          expected std::boxed::Box<(dyn std::ops::Fn() -> &'a T + 'a)>
             found std::boxed::Box<dyn std::ops::Fn() -> &T>

我不理解冲突。我该如何解决？

Answer 1

非常有趣的问题!我想我了解这里存在的问题。让我尝试解释一下。

tl; dr:闭包无法返回对通过移动捕获的值的引用，因为这将是对self的引用。不能返回这样的引用，因为Fn*特性不允许我们表达它。 这与streaming iterator problem基本相同，可以通过GAT(通用关联类型)进行修复。

手动实现

您可能知道，编写闭包时，编译器将为适当的impl特性生成struct和Fn块，因此闭包基本上是语法糖。让我们尝试避免所有麻烦，并手动构建您的类型。

您想要的是一个拥有另一种类型并可以返回对该拥有类型的引用的类型。并且您想要一个函数来返回所述类型的装箱实例。

struct Baz<T>(T);

impl<T> Baz<T> {
    fn call(&self) -> &T {
        &self.0
    }
}

fn make_baz<T>(t: T) -> Box<Baz<T>> {
    Box::new(Baz(t))
}

这与盒装闭包相当。让我们尝试使用它:

let outside = {
    let s = "hi".to_string();
    let baz = make_baz(s);
    println!("{}", baz.call()); // works

    baz
};

println!("{}", outside.call()); // works too

这样很好。字符串s被移动到Baz类型，并且该Baz实例被移动到Box。 s现在由baz拥有，然后再由outside拥有。

当我们添加一个字符时，它会变得更加有趣:

let outside = {
    let s = "hi".to_string();
    let baz = make_baz(&s);  // <-- NOW BORROWED!
    println!("{}", baz.call()); // works

    baz
};

println!("{}", outside.call()); // doesn't work!

现在，我们不能使baz的生存期大于s的生存期，因为baz包含对s的引用，这将是对s的悬挂引用，它将早于baz超出范围。

我想用这个片段来说明这一点:我们不需要在Baz类型上注释任何生存期，就可以使其安全； Rust自己搞清楚了，并强制baz的生存期不超过s。这在下面很重要。

为此写一个特质

到目前为止，我们仅介绍了基础知识。让我们尝试编写类似Fn的特征，以更接近您的原始问题:

trait MyFn {
    type Output;
    fn call(&self) -> Self::Output;
}

在我们的特征中，没有函数参数，但是与the real Fn trait完全相同。

让我们实现它!

impl<T> MyFn for Baz<T> {
    type Output = ???;
    fn call(&self) -> Self::Output {
        &self.0
    }
}

现在我们有一个问题:我们写什么而不是???？天真的会写&T ...，但是我们需要一个生命周期参数作为该引用。我们在哪里得到一个？返回值甚至有什么生命周期？

让我们检查一下我们之前实现的功能:

impl<T> Baz<T> {
    fn call(&self) -> &T {
        &self.0
    }
}

因此，这里我们也使用不带生命周期参数的&T。但这仅是由于终身淘汰而起作用。基本上，编译器会填充空格，以便fn call(&self) -> &T等效于:

fn call<'s>(&'s self) -> &'s T

啊哈，所以返回的引用的生存期绑定(bind)到self的生存期! (更多有经验的Rust用户可能已经感觉到这种情况了……)。

(作为附带说明:为什么返回的引用不依赖于T本身的生存期？如果T引用了非'static的某些内容，那么必须对此进行解释，对吗？是的，但它已经被解释了!请记住，没有实例Baz<T>的生命周期可能比T可能引用的生命周期更长。因此self的生存期已经比T可能具有的生存期更短。因此，我们只需要关注self的生存期即可)

但是，我们如何在特质隐含中表达这一点呢？原来:我们还不能(尚未)。在流式迭代器的上下文中经常提到此问题，也就是说，迭代器返回的项的生存期绑定(bind)到self生存期。在当今的Rust中，实现这一点令人遗憾地是不可能的。类型系统不够强大。

future 呢？

幸运的是，有一个RFC "Generic Associated Types"已在一段时间前合并。该RFC扩展了Rust类型系统，以允许相关的特征类型是通用的(在其他类型和生存期内)。

让我们看看如何使您的示例(kinda)与GAT一起使用(根据RFC；这东西还不起作用☹)。首先，我们必须更改特征定义:

trait MyFn {
    type Output<'a>;   // <-- we added <'a> to make it generic
    fn call(&self) -> Self::Output;
}

代码中的函数签名没有更改，但是请注意，终生淘汰开始了!上面的fn call(&self) -> Self::Output等效于:

fn call<'s>(&'s self) -> Self::Output<'s>

因此，关联类型的生存期绑定(bind)到self生存期。就像我们想要的一样! impl看起来像这样:

impl<T> MyFn for Baz<T> {
    type Output<'a> = &'a T;
    fn call(&self) -> Self::Output {
        &self.0
    }
}

要返回装箱的MyFn，我们需要编写此代码(根据this section of the RFC:

fn make_baz<T>(t: T) -> Box<for<'a> MyFn<Output<'a> = &'a T>> {
    Box::new(Baz(t))
}

如果我们想使用真正的Fn特性，该怎么办？据我了解，即使使用GAT，我们也做不到。我认为不可能更改现有的Fn特性以向后兼容的方式使用GAT。因此，标准库可能会保留较弱的特征。 (旁注:如何使用向后不兼容的方式来发展标准库以使用新的语言功能已经是I wondered about了几次；到目前为止，我还没有听说过这方面的任何实际计划；我希望Rust小组提出来某物...)

概括

从技术上来讲，您想要的不是不可能或不安全的(我们将其实现为简单的结构，并且可以正常工作)。但是，不幸的是，目前无法在Rust的类型系统中以闭包/Fn特征的形式表达您想要的内容。这与流式迭代器正在处理的问题相同。

利用计划的GAT功能，可以在类型系统中表达所有这些信息。但是，标准库需要以某种方式 catch 来，以使您的确切代码成为可能。