@ -1,20 +1,18 @@
## 生命周期与引用有效性
> [ch10-03-lifetime-syntax.md ](https://github.com/rust-lang/book/blob/master/s econd-edition/s rc/ch10-03-lifetime-syntax.md)
> [ch10-03-lifetime-syntax.md ](https://github.com/rust-lang/book/blob/master/s rc/ch10-03-lifetime-syntax.md)
> < br >
> commit fa0e4403f8350287b034c5b64af752f647ebb5a2
> commit 1fedfc4b96c2017f64ecfcf41a0a07e2e815f24f
当在第四章讨论引用时， ： ** 生命周期**（
当在第四章讨论 “ 引用和借用” 部分 时， ： ** 生命周期**（
好吧，这有点不太寻常，而且也不同于其他语言中使用的工具。生命周期，从某种意义上说，是 Rust 最与众不同的功能。
生命周期是一个很广泛的话题，本章不可能涉及到它全部的内容，所以这里我们会讲到一些通常你可能会遇到的生命周期语法以便你熟悉这个概念。第十九章会包含生命周期所有功能的更高级的内容。
生命周期的概念某种程度上说不同于其他语言中类似的工具，毫无疑问这是 Rust 最与众不同的功能。虽然本章不可能涉及到它全部的内容，我们会讲到一些通常你可能会遇到的生命周期语法以便你熟悉这个概念。查看第十九章 “高级生命周期” 部分了解更多的细节。
### 生命周期避免了悬垂引用
生命周期的主要目标是避免悬垂引用，它会导致程序引用了非预期引用的数据。考虑一下示例 10-18 中的程序，它有一个外部作用域和一个内部作用域，外部作用域声明了一个没有初值的变量 `r` ，而内部作用域声明了一个初值为 5 的变量`x`。在内部作用域中，我们尝试将 `r` 的值设置为一个 `x` 的引用。接着在内部作用域结束后，尝试打印出 `r` 的值：
生命周期的主要目标是避免悬垂引用，它会导致程序引用了非预期引用的数据。考虑一下示例 10-17 中的程序，它有一个外部作用域和一个内部作用域.
```rust,ignore
```rust,ignore,does_not_compile
{
let r;
@ -27,16 +25,15 @@
}
```
< span class = "caption" > 示例 10-18 ：尝试使用离开作用域的值的引用< / span >
< span class = "caption" > 示例 10-17 ：尝试使用离开作用域的值的引用< / span >
> #### 未初始化变量不能被使用
>
> 接下来的一些例子中声明了没有初始值的变量，以便这些变量存在于外部作用域。这看起来好像和 Rust 不允许存在空值相冲突。然而这是可以的，如果我们尝试在给它一个值之前使用这个变量，会出现一个编译时错误。请自行尝试！
> 注意：示例 10-17、10-18 和 10-24 中声明了没有初始值的变量，所以这些变量存在于外部作用域。这乍看之下好像和 Rust 不允许存在空值相冲突。然而如果尝试在给它一个值之前使用这个变量，会出现一个编译时错误，这就说明了 Rust 确实不允许空值。
当编译这段代码时会得到一个错误 ：
外部作用域声明了一个没有初值的变量 `r` ，而内部作用域声明了一个初值为 5 的变量`x`。在内部作用域中，我们尝试将 `r` 的值设置为一个 `x` 的引用。接着在内部作用域结束后，尝试打印出 `r` 的值。这段代码不能编译因为 `r` 引用的值在尝试使用之前就离开了作用域。如下是错误信息：
```text
error: `x` does not live long enough
error[E0597]: `x` does not live long enough
--> src/main.rs:7:5
|
6 | r = &x;
| - borrow occurs here
@ -47,51 +44,43 @@ error: `x` does not live long enough
| - borrowed value needs to live until here
```
变量 `x` 并没有 “存在的足够久”。为什么呢？好吧，`x` 在到达第 7 行的大括号的结束时就离开了作用域，这也是内部作用域的结尾。不过 `r` 在外部作用域也 是有效的；作用域越大我们就说它 “存在的越久”。如果 Rust 允许这段代码工作，`r` 将会引用在 `x` 离开作用域时被释放的内存，这时尝试对 `r` 做任何操作都会 不能正常工作。那么 Rust 是如何决定这段代码是不被允许的呢？
变量 `x` 并没有 “存在的足够久”。其原因是 `x` 在到达第 7 行内部作用域结束时就离开了作用域。不过 `r` 在外部作用域仍 是有效的；作用域越大我们就说它 “存在的越久”。如果 Rust 允许这段代码工作，`r` 将会引用在 `x` 离开作用域时被释放的内存，这时尝试对 `r` 做任何操作都不能正常工作。那么 Rust 是如何决定这段代码是不被允许的呢？这得益于借用检查器。
#### 借用检查器
编译器的这一部分叫做 ** 借用检查器**（ 9 展示了与示例 10-18 相同的例子不过带有变量生命周期的注释：
Rust 编译器有一个 ** 借用检查器**（ 8 展示了与示例 10-17 相同的例子不过带有变量生命周期的注释：
```rust,ignore
```rust,ignore,does_not_compile
{
let r; // -------+-- 'a
// |
{ // |
let x = 5; // -+-----+-- 'b
r = &x; // | |
} // -+ |
// |
println!("r: {}", r); // |
} // -------+
let r; // --------- +-- 'a
// |
{ // |
let x = 5; // -+-- 'b |
r = &x; // | |
} // -+ |
// |
println!("r: {}", r); // |
} // --------- +
```
< span class = "caption" > 示例 10-19 ： `x` 的生命周期注解，分别叫做 `'a` 和 `'b` </ span >
< span class = "caption" > 示例 10-18 ： `x` 的生命周期注解，分别叫做 `'a` 和 `'b` </ span >
<!-- Just checking I'm reading this right: the inside block is the b lifetime,
correct? I want to leave a note for production, make sure we can make that
clear -->
<!-- Yes, the inside block for the `'b` lifetime starts with the `let x = 5;`
line and ends with the first closing curly brace on the 7th line. Do you think
the text art comments work or should we make an SVG diagram that has nicer
looking arrows and labels? /Carol -->
这里将 `r` 的生命周期标记为 `'a` 并将 `x` 的生命周期标记为 `'b` 。如你所见，内部的 `'b` 块要比外部的生命周期 `'a` 小得多。在编译时， `r` 拥有生命周期 `'a` ，不过它引用了一个拥有生命周期 `'b` 的对象。程序被拒绝编译，因为生命周期 `'b` 比生命周期 `'a` 要小：被引用的对象比它的引用者存在的时间更短。
我们将 `r` 的生命周期标记为 `'a` 并将 `x` 的生命周期标记为 `'b` 。如你所见，内部的 `'b` 块要比外部的生命周期 `'a` 小得多。在编译时， `r` 拥有生命周期 `'a` ，不过它引用了一个拥有生命周期 `'b` 的对象。程序被拒绝编译，因为生命周期 `'b` 比生命周期 `'a` 要小：被引用的对象比它的引用者存在的时间更短。
让我们看看示例 10-20 中这个并没有产生悬垂引用且可以正确编译的例子：
让我们看看示例 10-19 中这个并没有产生悬垂引用且可以正确编译的例子：
```rust
{
let x = 5; // -----+-- 'b
// |
let r = &x; // --+--+-- 'a
// | |
println!("r: {}", r); // | |
// --+ |
} // -----+
let x = 5; // ----------+-- 'b
// |
let r = &x; // --+-- 'a |
// | |
println!("r: {}", r); // | |
// --+ |
} // ---------- +
```
< span class = "caption" > 示例 10-20 ：一个有效的引用，因为数据比引用有着更长的生命周期< / span >
< span class = "caption" > 示例 10-19 ：一个有效的引用，因为数据比引用有着更长的生命周期< / span >
这里 `x` 拥有生命周期 `'b` ，比 `'a` 要大。这就意味着 `r` 可以引用 `x` ： `r` 中的引用在 `x` 有效的时候也总是有效的。
@ -99,7 +88,7 @@ looking arrows and labels? /Carol -->
### 函数中的泛型生命周期
让我们来编写一个返回两个字符串 slice 中较长者的函数。我们希望能够通过传递两个字符串 slice 来调用这个函数，并希望返回一个字符串 slice。一旦我们实现了 `longest` 函数，示例 10-21 中的代码应该会打印出 `The longest string is abcd` ：
让我们来编写一个返回两个字符串 slice 中较长者的函数。这个函数获取两个字符串 slice 并返回一个字符串 slice。一旦我们实现了 `longest` 函数，示例 10-20 中的代码应该会打印出 `The longest string is abcd` ：
< span class = "filename" > 文件名: src/main.rs< / span >
@ -113,34 +102,15 @@ fn main() {
}
```
< span class = "caption" > 示例 10-21： `longest` 函数来寻找两个字符串 slice 中较长的一个</ span >
注意函数期望获取字符串 slice（ ） `String` 的 slice（ `string1` 的类型）以及字符串字面值（也就是变量 `string2` 包含的值）。
<!-- why is `a` a slice and `b` a literal? You mean "a" from the string "abcd"? -->
<!-- I've changed the variable names to remove ambiguity between the variable
name `a` and the "a" from the string "abcd". `string1` is not a slice, it's a
`String` , but we're going to pass a slice that refers to that `String` to the
`longest` function (`string1.as_str()` creates a slice that references the
`String` stored in `string1` ). We chose to have `string2` be a literal since
the reader might have code with both `String` s and string literals, and the way
most readers first get into problems with lifetimes is involving string slices,
so we wanted to demonstrate the flexibility of taking string slices as
arguments but the issues you might run into because string slices are
references.
All of the `String` /string slice/string literal concepts here are covered
thoroughly in Chapter 4, which is why we put two back references here (above
and below). If these topics are confusing you in this context, I'd be
interested to know if rereading Chapter 4 clears up that confusion.
/Carol -->
< span class = "caption" > 示例 10-20： `longest` 函数来寻找两个字符串 slice 中较长的一个</ span >
参考之前第四章中的 “字符串 slice 作为参数” 部分中更多关于为什么上面例子中的参数正符合我们期望的讨论。
如果尝试像示例 10-22 中那样实现 `longest` 函数，它并不能编译：
如果尝试像示例 10-21 中那样实现 `longest` 函数，它并不能编译：
< span class = "filename" > 文件名: src/main.rs< / span >
```rust,ignore
```rust,ignore,does_not_compile
fn longest(x: & str, y: & str) -> & str {
if x.len() > y.len() {
x
@ -150,43 +120,44 @@ fn longest(x: &str, y: &str) -> &str {
}
```
< span class = "caption" > 示例 10-22 ：一个 `longest` 函数的实现，它返回两个字符串 slice 中较长者，现在还不能编译</ span >
< span class = "caption" > 示例 10-21 ：一个 `longest` 函数的实现，它返回两个字符串 slice 中较长者，现在还不能编译</ span >
将 会出现如下有关生命周期的错误：
相应地 会出现如下有关生命周期的错误：
```text
error[E0106]: missing lifetime specifier
|
1 | fn longest(x: & str, y: & str) -> & str {
| ^ expected lifetime parameter
|
= help: this function's return type contains a borrowed value, but the
signature does not say whether it is borrowed from `x` or `y`
--> src/main.rs:1:33
|
1 | fn longest(x: & str, y: & str) -> & str {
| ^ expected lifetime parameter
|
= help: this function's return type contains a borrowed value, but the
signature does not say whether it is borrowed from `x` or `y`
```
提示文本告诉我们 返回值需要一个泛型生命周期参数，因为 Rust 并不知道将要返回的引用是指向 `x` 或 `y` 。事实上我们也不知道，因为函数体中 `if` 块返回一个 `x` 的引用而 `else` 块返回一个 `y` 的引用。
提示文本揭示了 返回值需要一个泛型生命周期参数，因为 Rust 并不知道将要返回的引用是指向 `x` 或 `y` 。事实上我们也不知道，因为函数体中 `if` 块返回一个 `x` 的引用而 `else` 块返回一个 `y` 的引用！
虽然我们定义了这个函数，但是 并不知道传递给函数的具体值，所以也不知道到底是 `if` 还是 `else` 会被执行。我们也不知道传入的引用的具体生命周期，所以也就不能像示例 10-19 和 10-20 那样通过观察作用域来确定返回的引用是否总是有效。借用检查器自身同样也无法确定，因为它不知道 `x` 和 `y` 的生命周期是如何与返回值的生命周期相关联的。接下来 我们将增加泛型生命周期参数来定义引用间的关系以便借用检查器可以进行分析。
当我们定义这个函数的时候， 并不知道传递给函数的具体值，所以也不知道到底是 `if` 还是 `else` 会被执行。我们也不知道传入的引用的具体生命周期，所以也就不能像示例 10-18 和 10-19 那样通过观察作用域来确定返回的引用是否总是有效。借用检查器自身同样也无法确定，因为它不知道 `x` 和 `y` 的生命周期是如何与返回值的生命周期相关联的。为了修复这个错误， 我们将增加泛型生命周期参数来定义引用间的关系以便借用检查器可以进行分析。
### 生命周期注解语法
生命周期注解并不改变任何引用的生命周期的长短。与当函数签名中指定了泛型类型参数后就可以接受任何类型一样，当指定了泛型生命周期后函数也能接受任何生命周期的引用。生命周期注解所做的就是将多个引用的生命周期联系起来 。
生命周期注解并不改变任何引用的生命周期的长短。与当函数签名中指定了泛型类型参数后就可以接受任何类型一样，当指定了泛型生命周期后函数也能接受任何生命周期的引用。生命周期注解描述了多个引用生命周期相互的关系，而不影响其生命周期 。
生命周期注解有着一个不太常见的语法：生命周期参数名称必须以撇号（`'`）开头。生命周期参数的名称通常全是小写，而且类似于泛型类型，其名称通常 非常短。`'a` 是大多数人默认使用的名称。生命周期参数注解位于引用的 `&` 之后，并有一个空格来将引用类型与生命周期注解分隔开。
生命周期注解有着一个不太常见的语法：生命周期参数名称必须以撇号（`'`）开头，其名称通常全是小写，类似于泛型其名称 非常短。`'a` 是大多数人默认使用的名称。生命周期参数注解位于引用的 `&` 之后，并有一个空格来将引用类型与生命周期注解分隔开。
这里有一些例子：我们有一个没有生命周期参数的 `i32` 的引用，一个有叫做 `'a` 的生命周期参数的 `i32` 的引用，和一个生命周期也是 `'a` 的 `i32` 的可变引用：
```rust,ignore
& i32 // a reference
& 'a i32 // a reference with an explicit lifetime
& 'a mut i32 // a mutable reference with an explicit lifetime
& i32 // 引用
& 'a i32 // 带有显式生命周期的引用
& 'a mut i32 // 带有显式生命周期的可变引用
```
单个的生命周期注解本身没有多少意义： `'a` 的 `i32` 的引用的参数 `first` ， `'a` 的 `i32` 的引用的参数 `second` ，这两个生命周期注解有相同的名称意味着 `first` 和 `second` 必须与这相同的 泛型生命周期存在得一样久。
单个的生命周期注解本身没有多少意义，因为 生命周期注解告诉 Rust 多个引用的泛型生命周期参数如何相互联系的 。例如 如果函数有一个生命周期 `'a` 的 `i32` 的引用的参数 `first` 。 还有另一个同样是生命周期 `'a` 的 `i32` 的引用的参数 `second` 。这两个生命周期注解意味着引用 `first` 和 `second` 必须与这泛型生命周期存在得一样久。
### 函数签名中的生命周期注解
来看看我们编写的 `longest` 函数的上下文中的生命周期。就像泛型类型参数，泛型生命周期参数需要声明在函数名和参数列表间的尖括号中。这里我们想要告诉 Rust 关于参数中的引用和返回值之间的限制是他们都必须拥有相同的生命周期，就像示例 10-23 中在每个引用中都加上了 `'a` 那样：
现在 来看看 `longest` 函数的上下文中的生命周期。就像泛型类型参数，泛型生命周期参数需要声明在函数名和参数列表间的尖括号中。这里我们想要告诉 Rust 关于参数中的引用和返回值之间的限制是他们都必须拥有相同的生命周期，就像示例 10-22 中在每个引用中都加上了 `'a` 那样：
< span class = "filename" > 文件名: src/main.rs< / span >
@ -200,19 +171,17 @@ fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
}
```
< span class = "caption" > 示例 10-23 ： `'a` </ span >
< span class = "caption" > 示例 10-22 ： `'a` </ span >
这段代码能够编译并会产生我们希望得到的示例 10-21 中的 `main` 函数的结果。
这段代码能够编译并会产生我们希望得到的示例 10-20 中的 `main` 函数的结果。
现在函数签名表明对于某些生命周期 `'a` ，函数会获取两个参数，他们都是与生命周期 `'a` 存在的一样长的字符串 slice。函数会返回一个同样也与生命周期 `'a` 存在的一样长的字符串 slice。这就是我们告诉 Rust 需要其保证的契约。
现在函数签名表明对于某些生命周期 `'a` ，函数会获取两个参数，他们都是与生命周期 `'a` 存在的一样长的字符串 slice。函数会返回一个同样也与生命周期 `'a` 存在的一样长的字符串 slice。这就是我们告诉 Rust 需要其保证的契约。记住通过在函数签名中指定生命周期参数时，我们并没有改变任何传入后返回的值的生命周期。而是指出任何不遵守这个协议的传入值都将被借用检查器拒绝。注意 `longest` 函数并不需要知道 `x` 和 `y` 具体会存在多久，而只需要知道有某个可以被 `'a` 替代的作用域将会满足这个签名。
通过在函数签名中指定生命周期参数，我们并没有改变任何传入后返回的值的生命周期，而是指出任何不遵守这个协议的传入值都将被借用检查器拒绝。这个函数并不知道（或需要知道）`x` 和 `y` 具体会存在多久，而只需要知道有某个可以被 `'a` 替代的作用域将会满足这个签名 。
当在函数中使用生命周期注解时，这些注解出现在函数签名中，而不存在于函数体中的任何代码中。这是因为 Rust 能够分析函数中代码而不需要任何协助，不过当函数引用或被函数之外的代码引用时，让 Rust 自身分析出参数或返回值的生命周期几乎是不可能的。这些生命周期在每次函数被调用时都可能不同。这也就是为什么我们需要手动标记生命周期 。
当在函数中使用生命周期注解时，这些注解出现在函数签名中，而不存在于函数体中的任何代码中。这是因为 Rust 能够分析函数中代码而不需要任何协助，不过当函数引用或被函数之外的代码引用时，参数或返回值的生命周期可能在每次函数被调用时都不同。这可能会产生惊人的消耗并且对于 Rust 来说通常是不可能分析的。在这种情况下，我们需要自己标注生命周期 。
当具体的引用被传递给 `longest` 时，被 `'a` 所替代的具体生命周期是 `x` 的作用域与 `y` 的作用域相重叠的那一部分。换一种说法就是泛型生命周期 `'a` 的具体生命周期等同于 `x` 和 `y` 的生命周期中较小的那一个。因为我们用相同的生命周期参数 `'a` 标注了返回的引用值，所以返回的引用值就能保证在 `x` 和 `y` 中较短的那个生命周期结束之前保持有效 。
当具体的引用被传递给 `longest` 时，被 `'a` 所替代的具体生命周期是 `x` 的作用域与 `y` 的作用域相重叠的那一部分。因为作用域总是嵌套的，所以换一种说法就是泛型生命周期 `'a` 的具体生命周期等同于 `x` 和 `y` 的生命周期中较小的那一个。因为我们用相同的生命周期参数 `'a` 标注了返回的引用值，所以返回的引用值就能保证在 `x` 和 `y` 中较短的那个生命周期结束之前保持有效。
让我们看看如何通过传递拥有不同具体生命周期的引用来限制 `longest` 函数的使用。示例 10-24 是一个应该在任何编程语言中都很直观的例子：`string1` 直到外部作用域结束都是有效的，`string2` 则在内部作用域中是有效的，而 `result` 则引用了一些直到内部作用域结束都是有效的值。借用检查器认可这些代码；它能够编译和运行，并打印出 `The longest string is long string is long` ：
让我们看看如何通过传递拥有不同具体生命周期的引用来限制 `longest` 函数的使用。示例 10-23 是一个很直观的例子。
< span class = "filename" > 文件名: src/main.rs< / span >
@ -236,13 +205,15 @@ fn main() {
}
```
< span class = "caption" > 示例 10-24： `String` 值调用 `longest` 函数</ span >
< span class = "caption" > 示例 10-23： `String` 值调用 `longest` 函数</ span >
在这个例子中，`string1` 直到外部作用域结束都是有效的，`string2` 则在内部作用域中是有效的，而 `result` 则引用了一些直到内部作用域结束都是有效的值。借用检查器认可这些代码；它能够编译和运行，并打印出 `The longest string is long string is long` 。
接下来，让我们尝试一个 `result` 的引用的生命周期肯定比两个参数的要短的例子。将 `result` 变量的声明从内部作用域中移动出来，但是将 `result` 和 `string2` 变量的赋值语句一同留在内部作用域里。接下来，我们将使用 `result` 的 `println!` 移动到内部作用域之外，就在其结束之后。注意示例 10-25 中的代码不能编译：
接下来，让我们尝试一个 `result` 的引用的生命周期肯定比两个参数的要短的例子。将 `result` 变量的声明从内部作用域中移动出来，但是将 `result` 和 `string2` 变量的赋值语句一同留在内部作用域里。接下来，我们将使用 `result` 的 `println!` 移动到内部作用域之外，就在其结束之后。注意示例 10-24 中的代码不能编译：
< span class = "filename" > 文件名: src/main.rs< / span >
```rust,ignore
```rust,ignore,does_not_compile
fn main() {
let string1 = String::from("long string is long");
let result;
@ -254,25 +225,26 @@ fn main() {
}
```
< span class = "caption" > 示例 10-25 ：在 `string2` 离开作用域之后使用 `result` 的尝试不能编译</ span >
< span class = "caption" > 示例 10-24 ：在 `string2` 离开作用域之后使用 `result` 的尝试不能编译</ span >
如果尝试编译会出现如下错误：
```text
error: `string2` does not live long enough
error[E0597]: `string2` does not live long enough
--> src/main.rs:15:5
|
6 | result = longest(string1.as_str(), string2.as_str());
14 | result = longest(string1.as_str(), string2.as_str());
| ------- borrow occurs here
7 | }
15 | }
| ^ `string2` dropped here while still borrowed
8 | println!("The longest string is {}", result);
9 | }
16 | println!("The longest string is {}", result);
17 | }
| - borrowed value needs to live until here
```
错误表明为了保证 `println!` 中的 `result` 是有效的，`string2` 需要直到外部作用域结束都是有效的。Rust 知道这些是因为（`longest`）函数的参数和返回值都使用了相同的生命周期参数 `'a` 。
以人类的理解 `string1` 更长，因此 `result` 会包含指向 `string1` 的引用。因为 `string1` 尚未离开作用域，对于 `println!` 来说 `string1` 的引用仍然是有效的。然而，我们通过生命周期参数告诉 Rust 的是 `longest` 函数返回的引用的生命周期应该与传入参数的生命周期中较短那个保持一致。因此，借用检查器不允许示例 10-25 中的代码，因为它可能会存在无效的引用。
以人类的理解 `string1` 更长，因此 `result` 会包含指向 `string1` 的引用。因为 `string1` 尚未离开作用域，对于 `println!` 来说 `string1` 的引用仍然是有效的。然而，我们通过生命周期参数告诉 Rust 的是 `longest` 函数返回的引用的生命周期应该与传入参数的生命周期中较短那个保持一致。因此，借用检查器不允许示例 10-24 中的代码，因为它可能会存在无效的引用。
请尝试更多采用不同的值和不同生命周期的引用作为 `longest` 函数的参数和返回值的实验。并在开始编译前猜想你的实验能否通过借用检查器，接着编译一下看看你的理解是否正确！
@ -294,7 +266,7 @@ fn longest<'a>(x: &'a str, y: &str) -> &'a str {
< span class = "filename" > 文件名: src/main.rs< / span >
```rust,ignore
```rust,ignore,does_not_compile
fn longest< 'a>(x: & str, y: & str) -> & 'a str {
let result = String::from("really long string");
result.as_str()
@ -304,18 +276,23 @@ fn longest<'a>(x: &str, y: &str) -> &'a str {
即便我们为返回值指定了生命周期参数 `'a` ，这个实现却编译失败了，因为返回值的生命周期与参数完全没有关联。这里是会出现的错误信息：
```text
error: `result` does not live long enough
error[E0597]: `result` does not live long enough
--> src/main.rs:3:5
|
3 | result.as_str()
| ^^^^^^ does not live long enough
4 | }
| - borrowed value only lives until here
|
note: borrowed value must be valid for the lifetime 'a as defined on the block
at 1:44...
note: borrowed value must be valid for the lifetime 'a as defined on the
function body at 1:1...
--> src/main.rs:1:1
|
1 | fn longest< 'a>(x: & str, y: & str) -> & 'a str {
| ^
1 | / fn longest< 'a>(x: & str, y: & str) -> & 'a str {
2 | | let result = String::from("really long string");
3 | | result.as_str()
4 | | }
| |_^
```
出现的问题是 `result` 在 `longest` 函数的结尾将离开作用域并被清理，而我们尝试从函数返回一个 `result` 的引用。无法指定生命周期参数来改变悬垂引用，而且 Rust 也不允许我们创建一个悬垂引用。在这种情况，最好的解决方案是返回一个有所有权的数据类型而不是一个引用，这样函数调用者就需要负责清理这个值了。
@ -324,7 +301,7 @@ at 1:44...
### 结构体定义中的生命周期注解
目前为止，我们只定义过有所有权类型的结构体。也可以定义存放引用的结构体，不过需要为结构体定义中的每一个引用添加生命周期注解。示例 10-26 中有一个存放了一个字符串 slice 的结构体 `ImportantExcerpt` ：
目前为止，我们只定义过有所有权类型的结构体。也可以定义存放引用的结构体，不过需要为结构体定义中的每一个引用添加生命周期注解。示例 10-25 中有一个存放了一个字符串 slice 的结构体 `ImportantExcerpt` ：
< span class = "filename" > 文件名: src/main.rs< / span >
@ -342,15 +319,15 @@ fn main() {
}
```
< span class = "caption" > 示例 10-26 ：一个存放引用的结构体，所以其定义需要生命周期注解< / span >
< span class = "caption" > 示例 10-25 ：一个存放引用的结构体，所以其定义需要生命周期注解< / span >
这个结构体有一个字段，`part`，它存放了一个字符串 slice， ， ，
这个结构体有一个字段，`part`，它存放了一个字符串 slice， ， ， 这个注解意味着 `ImportantExcerpt` 的示例不能比其 `part` 字段中的引用存在的更久。
这里的 `main` 函数创建了一个 `ImportantExcerpt` 的实例，它存放了变量 `novel` 所拥有的 `String` 的第一个句子的引用。
这里的 `main` 函数创建了一个 `ImportantExcerpt` 的实例，它存放了变量 `novel` 所拥有的 `String` 的第一个句子的引用。`novel` 的数据在 `ImportantExcerpt` 实例创建之前就存在。另外，直到 `ImportantExcerpt` 离开作用域之后 `novel` 都不会离开作用域，所以 `ImportantExcerpt` 实例中的引用是有效的
### 生命周期省略（ ）
在这一部分，我们知道了每一个引用都有一个生命周期，而且需要为使用了引用的函数或结构体指定生命周期。然而，第四章的 “字符串 slice” 部分有一个函数，我们在示例 10-27 中再次展示出来，它没有生命周期注解却能成功编译：
在这一部分，我们知道了每一个引用都有一个生命周期，而且需要为使用了引用的函数或结构体指定生命周期。然而，第四章的示例 4-9 中有一个函数，我们在示例 10-26 中再次展示出来，它没有生命周期注解却能成功编译：
< span class = "filename" > 文件名: src/lib.rs< / span >
@ -368,9 +345,9 @@ fn first_word(s: &str) -> &str {
}
```
< span class = "caption" > 示例 10-27： 第四章 定义了一个没有使用生命周期注解的函数，即便其参数和返回值都是引用< / span >
< span class = "caption" > 示例 10-27： 示例 4-9 定义了一个没有使用生命周期注解的函数，即便其参数和返回值都是引用< / span >
这个函数没有生命周期注解却能编译是由于一些历史原因：在早期 pre-1.0 版本 的 Rust 中，这的确是不能编译的。每一个引用都必须有明确的生命周期。那时的函数签名将会写成这样：
这个函数没有生命周期注解却能编译是由于一些历史原因：在早期版本（ ） 的 Rust 中，这的确是不能编译的。每一个引用都必须有明确的生命周期。那时的函数签名将会写成这样：
```rust,ignore
fn first_word< 'a>(s: & 'a str) -> & 'a str {
@ -384,23 +361,25 @@ fn first_word<'a>(s: &'a str) -> &'a str {
省略规则并不提供完整的推断：如果 Rust 在明确遵守这些规则的前提下变量的生命周期仍然是模棱两可的话，它不会猜测剩余引用的生命周期应该是什么。在这种情况，编译器会给出一个错误，这可以通过增加对应引用之间相联系的生命周期注解来解决。
首先，介绍一些定义：函数或方法的参数的生命周期被称为 ** 输入生命周期**（ ** 输出生命周期**（
函数或方法的参数的生命周期被称为 ** 输入生命周期**（ ** 输出生命周期**（
编译器采用三条规则来判断引用何时不需要明确的注解。第一条规则适用于输入生命周期，后两条规则适用于输出生命周期。如果编译器检查完这三条规则后仍然存在没有计算出生命周期的引用，编译器将会停止并生成错误。
现在介绍编译器用于判断引用何时不需要明确生命周期注解的规则。第一条规则适用于输入生命周期，后两条规则适用于输出生命周期。如果编译器检查完这三条规则后仍然存在没有计算出生命周期的引用，编译器将会停止并生成错误。
这些规则适用于 `fn` 定义，以及 `impl` 块 。
1. 每一个是引用的参数都有它自己的生命周期参数。换句话说就是，有一个引用参数的函数有一个生命周期参数：`fn foo< 'a>(x: & 'a i32)`，有两个引用参数的函数有两个不同的生命周期参数，`fn foo< 'a, 'b>(x: & 'a i32, y: & 'b i32)`，依此类推。
第一条规则是 每一个是引用的参数都有它自己的生命周期参数。换句话说就是，有一个引用参数的函数有一个生命周期参数：`fn foo< 'a>(x: & 'a i32)`，有两个引用参数的函数有两个不同的生命周期参数，`fn foo< 'a, 'b>(x: & 'a i32, y: & 'b i32)`，依此类推。
2. 如果只有一个输入生命周期参数，那么它被赋予所有输出生命周期参数：`fn foo< 'a>(x: & 'a i32) -> & 'a i32`。
第二条规则是 如果只有一个输入生命周期参数，那么它被赋予所有输出生命周期参数：`fn foo< 'a>(x: & 'a i32) -> & 'a i32`。
3. 如果方法有多个输入生命周期参数，不过其中之一因为方法的缘故为 `&self` 或 `&mut self` ，那么 `self` 的生命周期被赋给所有输出生命周期参数。这使得方法编写起来更简洁 。
第三条规则是 如果方法有多个输入生命周期参数，不过其中之一因为方法的缘故为 `&self` 或 `&mut self` ，那么 `self` 的生命周期被赋给所有输出生命周期参数。这使得方法更容易读写，因为只需更少的符号 。
假设我们自己就是编译器并来计算示例 10-25 `first_word` 函数的 签名中的引用的生命周期。开始时签名中的引用并没有关联任何生命周期：
假设我们自己就是编译器。并应用这些规则来计算示例 10-26 中 `first_word` 函数 签名中的引用的生命周期。开始时签名中的引用并没有关联任何生命周期：
```rust,ignore
fn first_word(s: & str) -> & str {
```
接着我们（作为 编译器） `'a` ，所以现在签名看起来像这样：
接着编译器应用第一条规则，也就是每个引用参数都有其自己的生命周期。我们像往常一样称之为 `'a` ，所以现在签名看起来像这样：
```rust,ignore
fn first_word< 'a>(s: & 'a str) -> & str {
@ -414,7 +393,7 @@ fn first_word<'a>(s: &'a str) -> &'a str {
现在这个函数签名中的所有引用都有了生命周期，如此编译器可以继续它的分析而无须程序员标记这个函数签名中的生命周期。
让我们再看看另一个例子，这次我们从示例 10-22 中没有生命周期参数的 `longest` 函数开始：
让我们再看看另一个例子，这次我们从示例 10-21 中没有生命周期参数的 `longest` 函数开始：
```rust,ignore
fn longest(x: & str, y: & str) -> & str {
@ -426,25 +405,17 @@ fn longest(x: &str, y: &str) -> &str {
fn longest< 'a, 'b>(x: & 'a str, y: & 'b str) -> & str {
```
再来应用第二条规则，它并不适用因为存在多于一个输入生命周期。再来看第三条规则，它同样也不适用因为没有 `self` 参数。然后我们就没有更多规则了，不过还没有计算出返回值的类型的生命周期。这就是为什么在编译示例 10-22 的代码时会出现错误的原因：编译器使用所有已知的生命周期省略规则，不过仍不能计算出签名中所有引用的生命周期。
再来应用第二条规则，它并不适用因为存在多于一个输入生命周期。再来看第三条规则，它同样也不适用因为没有 `self` 参数。然后我们就没有更多规则了，不过还没有计算出返回值的类型的生命周期。这就是为什么在编译示例 10-21 的代码时会出现错误的原因：编译器使用所有已知的生命周期省略规则，不过仍不能计算出签名中所有引用的生命周期。
因为第三条规则真正能够适用的就只有方法签名，现在就让我们看看那种情况中的生命周期，并看看为什么这条规则意味着我们经常不需要在方法签名中标注生命周期。
### 方法定义中的生命周期注解
<!-- Is this different to the reference lifetime annotations, or just a
finalized explanation? -->
<!-- This is about lifetimes on references in method signatures, which is where
the 3rd lifetime elision rule kicks in. It can also be confusing where lifetime
parameters need to be declared and used since the lifetime parameters could go
with the struct's fields or with references passed into or returned from
methods. /Carol -->
当为带有生命周期的结构体实现方法时，其语法依然类似示例 10-11 中展示的泛型类型参数的语法：声明和使用生命周期参数的位置依赖于生命周期参数是否同结构体字段或方法参数和返回值相关。
当为带有生命周期的结构体实现方法时，其语法依然类似示例 10-11 中展示的泛型类型参数的语法。声明和使用生命周期参数的位置依赖于生命周期参数是否同结构体字段或方法参数和返回值相关。
（实现方法时）结构体字段的生命周期必须总是在 `impl` 关键字之后声明并在结构体名称之后被使用，因为这些生命周期是结构体类型的一部分。
`impl` 块里的方法签名中，引用可能与结构体字段中的引用相关联，也可能是独立的。另外，生命周期省略规则也经常让我们无需在方法签名中使用生命周期注解。让我们看看一些使用示例 10-26 中定义的结构体 `ImportantExcerpt` 的例子。
`impl` 块里的方法签名中，引用可能与结构体字段中的引用相关联，也可能是独立的。另外，生命周期省略规则也经常让我们无需在方法签名中使用生命周期注解。让我们看看一些使用示例 10-25 中定义的结构体 `ImportantExcerpt` 的例子。
首先，这里有一个方法 `level` 。其唯一的参数是 `self` 的引用，而且返回值只是一个 `i32` ，并不引用任何值：
@ -481,7 +452,7 @@ impl<'a> ImportantExcerpt<'a> {
### 静态生命周期
这里有 ** 一种** 特殊的生命周期值得讨论：`'static`。`'static` 生命周期存活于整个程序期间。所有的字符串字面值都拥有 `'static` 生命周期，我们也可以选择像下面这样标注出来：
这里有一种特殊的生命周期值得讨论：`'static`，其 生命周期存活于整个程序期间。所有的字符串字面值都拥有 `'static` 生命周期，我们也可以选择像下面这样标注出来：
```rust
let s: & 'static str = "I have a static lifetime.";
@ -489,10 +460,7 @@ let s: &'static str = "I have a static lifetime.";
这个字符串的文本被直接储存在程序的二进制文件中而这个文件总是可用的。因此所有的字符串字面值都是 `'static` 的。
<!-- How would you add a static lifetime (below)? -->
<!-- Just like you'd specify any lifetime, see above where it shows `&'static str` . /Carol -->
你可能在错误信息的帮助文本中见过使用 `'static` 生命周期的建议，不过将引用指定为 `'static` 之前，思考一下这个引用是否真的在整个程序的生命周期里都有效（或者哪怕你希望它一直有效，如果可能的话）。大部分情况，代码中的问题是尝试创建一个悬垂引用或者可用的生命周期不匹配，请解决这些问题而不是指定一个 `'static` 的生命周期。
你可能在错误信息的帮助文本中见过使用 `'static` 生命周期的建议，不过将引用指定为 `'static` 之前，思考一下这个引用是否真的在整个程序的生命周期里都有效。你可能会考虑希望它一直有效，如果可能的话。大部分情况，代码中的问题是尝试创建一个悬垂引用或者可用的生命周期不匹配，请解决这些问题而不是指定一个 `'static` 的生命周期。
### 结合泛型类型参数、trait bounds 和生命周期
@ -513,7 +481,7 @@ fn longest_with_an_announcement<'a, T>(x: &'a str, y: &'a str, ann: T) -> &'a st
}
```
这个是示例 10-23 中那个返回两个字符串 slice 中较长者的 `longest` 函数，不过带有一个额外的参数 `ann` 。`ann` 的类型是泛型 `T` ，它可以被放入任何实现了 `where` 从句中指定的 `Display` trait 的类型。这个额外的参数会在函数比较字符串 slice 的长度之前被打印出来，这也就是为什么 `Display` trait bound 是必须的。因为生命周期也是泛型，所以生命周期参数 `'a` 和泛型类型参数 `T` 都位于函数名后的同一尖括号列表中。
这个是示例 10-22 中那个返回两个字符串 slice 中较长者的 `longest` 函数，不过带有一个额外的参数 `ann` 。`ann` 的类型是泛型 `T` ，它可以被放入任何实现了 `where` 从句中指定的 `Display` trait 的类型。这个额外的参数会在函数比较字符串 slice 的长度之前被打印出来，这也就是为什么 `Display` trait bound 是必须的。因为生命周期也是泛型，所以生命周期参数 `'a` 和泛型类型参数 `T` 都位于函数名后的同一尖括号列表中。
## 总结
KaiserY
6 years ago