问题描述
这可能是我不理解借用检查器的一些技术细节的教科书案例，但如果有人能帮我解决这个问题就好了。
pub struct Example(pub Vec<String>);
impl Example {
pub fn iter(&self) -> impl Iterator<Item=&String> {
self.0.iter()
}
}
pub fn some_condition(_: &str) -> bool {
// This is not important.
return false;
}
pub fn foo() -> bool {
let example = Example(vec!("foo".to_owned(),"bar".to_owned()));
let mut tmp = example.iter();
tmp.all(|x| some_condition(x))
}
pub fn main() {
println!("{}",foo());
}
然而，我尝试的第一件事（在我看来，应该等同于上面的），是完全省略临时变量 tmp，如下
pub fn foo() -> bool {
let example = Example(vec!("foo".to_owned(),"bar".to_owned()));
example.iter().all(|x| some_condition(x))
}
但是这个版本会产生以下错误。
error[E0597]: `example` does not live long enough
--> so_temporary.rs:23:3
|
23 | example.iter().all(|x| some_condition(x))
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
24 | }
| -
| |
| `example` dropped here while still borrowed
| ... and the borrow might be used here,when that temporary is dropped and runs the destructor for type `impl std::iter::Iterator`
|
= note: The temporary is part of an expression at the end of a block. Consider forcing this temporary to be dropped sooner,before the block's local variables are dropped. For example,you Could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block.
现在，显然，错误末尾的注释是一个很好的建议，这就是我引入临时解决问题的原因。但我不明白为什么可以解决这个问题。我的 tmp 变量的生命周期与直接嵌入到表达式中的 example.iter() 有什么不同，这使得一个工作一个失败？
解决方法
这与 Why do I get "does not live long enough" in a return value? 的答案基本相同，并且在错误本身中有一些解释，但我会详细说明。此行为与普通块表达式相同：
pub struct Example(pub Vec<String>);
impl Example {
pub fn iter(&self) -> impl Iterator<Item=&String> {
self.0.iter()
}
}
pub fn main() {
let foo = {
let example = Example(vec!("foo".to_owned(),"".to_owned()));
example.iter().all(String::is_empty)
};
println!("{}",foo);
}
error[E0597]: `example` does not live long enough
--> src/main.rs:12:9
|
12 | example.iter().all(String::is_empty)
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
13 | };
| -- ... and the borrow might be used here,when that temporary is dropped and runs the destructor for type `impl Iterator`
| |
| `example` dropped here while still borrowed
|
= note: the temporary is part of an expression at the end of a block;
consider forcing this temporary to be dropped sooner,before the block's local variables are dropped
help: for example,you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
|
12 | let x = example.iter().all(String::is_empty); x
| ^^^^^^^ ^^^
scope of temporary values 通常是创建它们的语句。在上面的代码中，example 是一个变量，它在块的末尾被销毁。但是，example.iter() 创建临时 impl Iterator，其临时范围是完整的 let foo = ... 语句。所以评估这个的步骤是：
- 评估
example.iter().all(...)的结果 - 放下
example - 将结果分配给
foo - 放下
impl Iterator
您可能会看到这可能出错的地方。引入变量的原因是因为它迫使任何临时变量更快地被删除。说到函数，情况略有不同，但效果是一样的：
在函数体的最终表达式中创建的临时对象在函数体中绑定的任何命名变量之后被删除，因为没有更小的封闭临时作用域。
关于评论：
-
当
impl Iterator替换为std::slice::Iter<'_,i32>时它起作用的原因（在 pretzelhammer 的示例中）是因为掉落检查器知道slice::Iter不t 访问example而它必须假设impl Iterator确实如此。 -
它与
fn my_all(mut self,...)一起使用的原因（在 Peter Hall 的例子中）是因为all通过引用获取迭代器，而my_all通过值获取它。临时impl Iterator在表达式结束前被消耗和销毁。
通过查看与此相关的各种 Rust 问题，很明显有些人会认为这是一个错误。 { ...; EXPR } 和 { ...; let x = EXPR; x } 可能不同，这绝对不明显。但是，由于添加了诊断和文档以加强和解释这种行为，我必须假设这些临时范围规则允许更合理的代码。