gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-29 07:41:48 25 4
gpt4 key购买 nike

考虑以下代码:

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

我的期望:
  • 类型T具有生命周期'a
  • tT一样长。
  • 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>

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

    最佳答案

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

    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实例被移动到 Boxs现在由 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 来,以使您的确切代码成为可能。

    关于rust - 无法为返回引用的闭包推断适当的生存期,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49806352/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com