引言

譯者：ssbunny（兔子不咬人）

這篇文章寫得很好，網(wǎng)上也有諸多譯文。之所以再譯一次，是因?yàn)槲覍@些譯文的質(zhì)量不太滿意。它們大多過于拗口，譯文無法突出原文所表達(dá)的重點(diǎn)，有些甚至存在錯譯。我謹(jǐn)慎地再譯一次，只為分享給你。

Intro（導(dǎo)言）

I've held all of these misconceptions at some point and I see many beginners struggle with these misconceptions today. Some of my terminology might be non-standard, so here's a table of shorthand phrases I use and what I intend for them to mean.

接下來要講的這些誤區(qū)我都曾陷入過，如今也看到許多初學(xué)者在其中掙扎?？赡芪沂褂玫男g(shù)語不標(biāo)準(zhǔn)，所以我列了個(gè)短語速記表，以闡述我想表達(dá)的意思。

The Misconceptions（誤區(qū)）

In a nutshell: A variable's lifetime is how long the data it points to can be statically verified by the compiler to be valid at its current memory address. I'll now spend the next ~6500 words going into more detail about where people commonly get confused.

一言以蔽之： 變量的生命周期是指編譯器可靜態(tài)驗(yàn)證變量指向的數(shù)據(jù)，在其當(dāng)前內(nèi)存地址的有效時(shí)間。接下來，我將用大約 6500 字（英文原文）的篇幅詳細(xì)介紹大家通常會混淆的地方。

1) T only contains owned types

（T 僅包含擁有所有權(quán)的類型）

This misconception is more about generics than lifetimes but generics and lifetimes are tightly intertwined in Rust so it's not possible to talk about one without also talking about the other. Anyway:

這一誤區(qū)更多源自對泛型的錯誤理解，而非生命周期。但在 Rust 中，泛型和生命周期是緊密相連的，談?wù)撈渲兄粫r(shí)不可能規(guī)避另一個(gè)不談。這么說吧：

When I first started learning Rust I understood that i32, &i32, and &mut i32 are different types. I also understood that some generic type variable T represents a set which contains all possible types. However, despite understanding both of these things separately, I wasn't able to understand them together. In my newbie Rust mind this is how I thought generics worked:

當(dāng)我剛開始學(xué)習(xí) Rust 時(shí)，我知道 i32、&i32 和 &mut i32 是不同的類型。我還知道泛型變量 T 代表一個(gè)集合，其中包含所有可能的類型。然而，盡管我分別理解了這兩件事，卻無法將它們放在一起理解。在我這個(gè) Rust 新手的腦海中，認(rèn)為泛型是這樣工作的：

T contains all owned types. &T contains all immutably borrowed types. &mut T contains all mutably borrowed types. T, &T, and &mut T are disjoint finite sets. Nice, simple, clean, easy, intuitive, and completely totally wrong. This is how generics actually work in Rust:

T 包含所有擁有所有權(quán)的類型。&T 包含所有不可變引用類型。&mut T 包含所有可變引用類型。T、&T 和 &mut T 是互不相交的有限集合。漂亮、簡單、干凈、容易、直觀，但完全是大錯特錯。事實(shí)上，在 Rust 中泛型是這樣工作的：

T, &T, and &mut T are all infinite sets, since it's possible to borrow a type ad-infinitum. T is a superset of both &T and &mut T. &T and &mut T are disjoint sets. Here's a couple examples which validate these concepts:

其實(shí) T、&T 和 &mut T 都是無限集，因?yàn)榭梢詿o限借用一個(gè)類型。T 是 &T 和 &mut T 的超集。下面是幾個(gè)驗(yàn)證這些概念的例子：

trait Trait {}
impl<T> Trait for T {}
impl<T> Trait for &T {} // ?
impl<T> Trait for &mut T {} // ?

The above program doesn't compile as expected:

上述代碼無法如期編譯：

error[E0119]: conflicting implementations of trait `Trait` for type `&_`:
 --> src/lib.rs:5:1
  |
3 | impl<T> Trait for T {}
  | ------------------- first implementation here
4 |
5 | impl<T> Trait for &T {}
  | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&_`

error[E0119]: conflicting implementations of trait `Trait` for type `&mut _`:
 --> src/lib.rs:7:1
  |
3 | impl<T> Trait for T {}
  | ------------------- first implementation here
...
7 | impl<T> Trait for &mut T {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&mut _`

The compiler doesn't allow us to define an implementation of Trait for &T and &mut T since it would conflict with the implementation of Trait for T which already includes all of &T and &mut T. The program below compiles as expected, since &T and &mut T are disjoint:

編譯器不允許我們?yōu)?nbsp;&T 和 &mut T 定義 Trait 的實(shí)現(xiàn)，因?yàn)檫@會與 T 對 Trait 的實(shí)現(xiàn)沖突，后者已經(jīng)包含了 &T 和 &mut T。由于 &T 和 &mut T 不相交，因此下面的代碼可以按預(yù)期編譯：

trait Trait {}
impl<T> Trait for &T {} // ?
impl<T> Trait for &mut T {} // ?

Key Takeaways

• T is a superset of both &T and &mut T
• &T and &mut T are disjoint sets

主要收獲

• T 是 &T 和 &mut T 的超集
• &T 和 &mut T 是互不相交的集合

2) if T: 'static then T must be valid for the entire program

（若 T: 'static 則 T 必須在整個(gè)程序運(yùn)行期間有效）

Misconception Corollaries

• T: 'static should be read as "T has a 'static lifetime"
• &'static T and T: 'static are the same thing
• if T: 'static then T must be immutable
• if T: 'static then T can only be created at compile time

誤區(qū)延伸

• T: 'static 被視作 "T 擁有 'static 生命周期"
• &'static T 與 T: 'static 相同
• 若 T: 'static 則 T 是不可變的
• 若 T: 'static 則 T 只能在編譯期創(chuàng)建

Most Rust beginners get introduced to the 'static lifetime for the first time in a code example that looks something like this:

多數(shù) Rust 初學(xué)者第一次接觸 'static 生命周期時(shí)，都見到過類似這種示例代碼：

fn main() {
    let str_literal: &'static str = "str literal";
}

They get told that "str literal" is hardcoded into the compiled binary and is loaded into read-only memory at run-time so it's immutable and valid for the entire program and that's what makes it 'static. These concepts are further reinforced by the rules surrounding defining static variables using the static keyword.

這些初學(xué)者們被告知："str literal" 已被硬編碼到編譯后的二進(jìn)制文件中，并會在運(yùn)行期加載到只讀內(nèi)存區(qū)，因此它是不可變的，在整個(gè)程序運(yùn)行期間都有效，這正是它之所以稱作 "static" 的原因。而 Rust 使用 static 關(guān)鍵字定義 static 變量的語法規(guī)則，更是進(jìn)一步強(qiáng)化了這種觀念。

// Note: This example is purely for illustrative purposes.
// Never use `static mut`. It's a footgun. There are
// safe patterns for global mutable singletons in Rust but
// those are outside the scope of this article.
// 注意：本例純粹用于演示說明，切勿使用 `static mut`。它是一把雙刃劍。
// 在 Rust 中有 safe 模式的全局可變單例，但這不在本文討論范圍。
static BYTES: [u8; 3] = [1, 2, 3];
static mut MUT_BYTES: [u8; 3] = [1, 2, 3];
fn main() {
   MUT_BYTES[0] = 99; // ? - mutating static is unsafe 修改靜態(tài)變量是 unsafe 操作
    unsafe {
        MUT_BYTES[0] = 99;
        assert_eq!(99, MUT_BYTES[0]);
    }
}

Regarding static variables

• they can only be created at compile-time
• they should be immutable, mutating them is unsafe
• they're valid for the entire program

關(guān)于靜態(tài)變量

• 它們只能在編譯時(shí)創(chuàng)建
• 它們是不可變的，改變它們是不安全的
• 它們在整個(gè)程序運(yùn)行期間有效

The 'static lifetime was probably named after the default lifetime of static variables, right? So it makes sense that the 'static lifetime has to follow all the same rules, right?

'static 生命周期可能得名于 static 變量的默認(rèn)生命周期，是這樣嗎？因此可以合理地認(rèn)為，static 生命周期必須遵循所有相同的規(guī)則，是這樣嗎？

Well yes, but a type with a 'static lifetime is different from a type bounded by a 'static lifetime. The latter can be dynamically allocated at run-time, can be safely and freely mutated, can be dropped, and can live for arbitrary durations.

是這樣的，但具有 'static 生命周期的類型和受 'static 生命周期約束的類型是不同的概念。后者可以在運(yùn)行期動態(tài)分配，可以安全、自由地修改，可以 drop，可以存活任意時(shí)長。

It's important at this point to distinguish &'static T from T: 'static.

在這一點(diǎn)上，區(qū)分 &'static T 和 T: 'static 至關(guān)重要。

&'static T is an immutable reference to some T that can be safely held indefinitely long, including up until the end of the program. This is only possible if T itself is immutable and does not move _after the reference was created_. T does not need to be created at compile-time. It's possible to generate random dynamically allocated data at run-time and return 'static references to it at the cost of leaking memory, e.g.

&'static T 是對 T 的不可變引用，該引用可以安全地、無限期駐留在內(nèi)存中，甚至到程序結(jié)束。然而只有當(dāng) T 本身是不可變的，并且在創(chuàng)建引用后不會移動時(shí)，才有可能做到這一點(diǎn)。T 不需要在編譯期創(chuàng)建。完全可以在運(yùn)行期生成隨機(jī)的動態(tài)分配數(shù)據(jù)，并以內(nèi)存泄漏為代價(jià)返回對它的 'static 引用，例如：

use rand;
// generate random 'static str refs at run-time
// 運(yùn)行期隨機(jī)生成 'static str 引用
fn rand_str_generator() -> &'static str {
    let rand_string = rand::random::<u64>().to_string();
    Box::leak(rand_string.into_boxed_str())
}

T: 'static is some T that can be safely held indefinitely long, including up until the end of the program. T: 'static includes all &'static T however it also includes all owned types, like String, Vec, etc. The owner of some data is guaranteed that data will never get invalidated as long as the owner holds onto it, therefore the owner can safely hold onto the data indefinitely long, including up until the end of the program. T: 'static should be read as "T is bounded by a 'static lifetime" not _"T has a 'static lifetime"_. A program to help illustrate these concepts:

T: 'static 則是指 T 本身可以安全地、無限期駐留在內(nèi)存中，甚至到程序結(jié)束。T: 'static 既包括所有 &'static T，也包括所有擁有所有權(quán)的類型，如 String、Vec 等。只要數(shù)據(jù)的所有者持有這些數(shù)據(jù)，就能保證其永不失效，也就是說所有者可以安全地、無限期地持有這些數(shù)據(jù)，直到程序結(jié)束。T: 'static 應(yīng)被視作 “T 受 'static 生命周期約束”，而不是 “T 擁有 'static 生命周期”。用程序來說明這一概念：

use rand;
fn drop_static<T: 'static>(t: T) {
    std::mem::drop(t);
}
fn main() {
    let mut strings: Vec<String> = Vec::new();
    for _ in 0..10 {
        if rand::random() {
            // all the strings are randomly generated
            // and dynamically allocated at run-time
            // 所有字符串都是隨機(jī)生成的，并在運(yùn)行期動態(tài)分配
            let string = rand::random::<u64>().to_string();
            strings.push(string);
        }
    }
    // strings are owned types so they're bounded by 'static
    // strings 是擁有所有權(quán)的類型，因此它們受 'static 約束
    for mut string in strings {
        // all the strings are mutable
        // 所有字符串都是可變的
        string.push_str("a mutation");
        // all the strings are droppable
        // 而且都可以被 drop
        drop_static(string); // ?
    }
    // all the strings have been invalidated before the end of the program
    // 在程序結(jié)束前，strings 都已失效
    println!("I am the end of the program");
}

Key Takeaways

• T: 'static should be read as "T is bounded by a 'static lifetime"
• if T: 'static then T can be a borrowed type with a 'static lifetime or an owned type

• since T: 'static includes owned types that means T

  • can be dynamically allocated at run-time
  • does not have to be valid for the entire program
  • can be safely and freely mutated
  • can be dynamically dropped at run-time
  • can have lifetimes of different durations

主要收獲

• T: 'static 應(yīng)被理解為 “T 受 'static 生命周期約束”
• 若 T: 'static 則 T 可以是擁有 'static 生命周期的借用類型 或 擁有所有權(quán)的類型

• 既然 T: 'static 包括擁有所有權(quán)的類型，便意味著 T

  • 可以在運(yùn)行期動態(tài)分配
  • 不必在整個(gè)程序運(yùn)行期間有效
  • 可以安全、自由地修改
  • 可以在運(yùn)行期動態(tài) drop
  • 可以有不同的生命周期

3) &'a T and T: 'a are the same thing（&'a T 和 T: 'a 相同）

This misconception is a generalized version of the one above.

這一誤區(qū)其實(shí)是上一個(gè)的泛化。

&'a T requires and implies T: 'a since a reference to T of lifetime 'a cannot be valid for 'a if T itself is not valid for 'a. For example, the Rust compiler will never allow the construction of the type &'static Ref<'a, T> because if Ref is only valid for 'a we can't make a 'static reference to it.

&'a T 要求并隱含了 T: 'a，因?yàn)槿绻?nbsp;T 本身對生命周期 'a 無效，那么生命周期為 'a 的 T 的引用更不可能對 'a 有效。比方說，Rust 編譯器從不允許構(gòu)造 &'static Ref<'a, T> 類型，正是因?yàn)槿绻?nbsp;Ref 只對 'a 有效，就不可能對它進(jìn)行 'static 引用。

T: 'a includes all &'a T but the reverse is not true.

T：'a 包括所有 &'a T，反之則不成立。

// only takes ref types bounded by 'a
// 只接受滿足生命周期 'a 的引用類型
fn t_ref<'a, T: 'a>(t: &'a T) {}
// takes any types bounded by 'a
// 接受滿足生命周期 'a 的所有類型
fn t_bound<'a, T: 'a>(t: T) {}
// owned type which contains a reference
// 擁有所有權(quán)的類型，其內(nèi)部包含引用
struct Ref<'a, T: 'a>(&'a T);
fn main() {
    let string = String::from("string");
    t_bound(&string); // ?
    t_bound(Ref(&string)); // ?
    t_bound(&Ref(&string)); // ?
    t_ref(&string); // ?
    t_ref(Ref(&string)); // ? - expected ref, found struct
    t_ref(&Ref(&string)); // ?
    // string var is bounded by 'static which is bounded by 'a
    // 字符串變量受 'static 約束，而 'static 受 'a 約束
    t_bound(string); // ?
}

Key Takeaways

• T: 'a is more general and more flexible than &'a T
• T: 'a accepts owned types, owned types which contain references, and references
• &'a T only accepts references
• if T: 'static then T: 'a since 'static >= 'a for all 'a

主要收獲

• 與 &'a T 相比，T: 'a 更通用、更靈活
• T: 'a 接受擁有所有權(quán)的類型（其內(nèi)部可含有引用）、引用類型
• &'a T 只接受引用類型
• 若 T: 'static 則 T: 'a ，因?yàn)閷τ谒?nbsp;'a 都有 'static >= 'a

4) my code isn't generic and doesn't have lifetimes

（我的代碼沒使用泛型也不含生命周期注解）

Misconception Corollaries

• it's possible to avoid using generics and lifetimes

誤區(qū)延伸

• 可以避免使用泛型和生命周期注解

This comforting misconception is kept alive thanks to Rust's lifetime elision rules, which allow you to omit lifetime annotations in functions because the Rust borrow checker will infer them following these rules:

• every input ref to a function gets a distinct lifetime
• if there's exactly one input lifetime it gets applied to all output refs
• if there's multiple input lifetimes but one of them is &self or &mut self then the lifetime of self is applied to all output refs
• otherwise output lifetimes have to be made explicit

這一看似令人舒適的誤區(qū)禍起自 Rust 的生命周期省略規(guī)則（lifetime elision rules），它允許在函數(shù)中省略生命周期注解。之所以能夠省略，是因?yàn)?Rust 的借用檢查器可以基于以下規(guī)則推斷出相應(yīng)的注解：

• 函數(shù)的每個(gè)輸入引用都有一個(gè)獨(dú)立的生命周期
• 如果有且只有一個(gè)輸入生命周期，該生命周期將應(yīng)用于所有輸出引用
• 如果有多個(gè)輸入生命周期，但其中一個(gè)是 &self 或 &mut self，那么 self 的生命周期將應(yīng)用于所有輸出引用
• 否則，必須明確指出輸出生命周期

That's a lot to take in so let's look at some examples:

要理解的有點(diǎn)多，不妨來看一些例子：

// elided 省略形式
fn print(s: &str);
// expanded 完整形式
fn print<'a>(s: &'a str);
// elided 省略形式
fn trim(s: &str) -> &str;
// expanded 完整形式
fn trim<'a>(s: &'a str) -> &'a str;
// illegal, can't determine output lifetime, no inputs
// 非法，無法確定輸出生命周期，無輸入
fn get_str() -> &str;
// explicit options include
// 顯式標(biāo)注
fn get_str<'a>() -> &'a str; // generic version 泛型版本
fn get_str() -> &'static str; // 'static version 'static 版本
// illegal, can't determine output lifetime, multiple inputs
// 非法，無法確定輸出生命周期，多輸入
fn overlap(s: &str, t: &str) -> &str;
// explicit (but still partially elided) options include
// 顯式標(biāo)注（但仍有部分標(biāo)注被省略）
fn overlap<'a>(s: &'a str, t: &str) -> &'a str; // output can't outlive s 返回值的生命周期不長于 s
fn overlap<'a>(s: &str, t: &'a str) -> &'a str; // output can't outlive t 返回值的生命周期不長于 t
fn overlap<'a>(s: &'a str, t: &'a str) -> &'a str; // output can't outlive s & t 返回值的生命周期不長于 s & t
fn overlap(s: &str, t: &str) -> &'static str; // output can outlive s & t 返回值的生命周期可以長于 s & t
fn overlap<'a>(s: &str, t: &str) -> &'a str; // no relationship between input & output lifetimes 返回值的生命周期與輸入無關(guān)
// expanded 完整形式
fn overlap<'a, 'b>(s: &'a str, t: &'b str) -> &'a str;
fn overlap<'a, 'b>(s: &'a str, t: &'b str) -> &'b str;
fn overlap<'a>(s: &'a str, t: &'a str) -> &'a str;
fn overlap<'a, 'b>(s: &'a str, t: &'b str) -> &'static str;
fn overlap<'a, 'b, 'c>(s: &'a str, t: &'b str) -> &'c str;
// elided 省略形式
fn compare(&self, s: &str) -> &str;
// expanded 完整形式
fn compare<'a, 'b>(&'a self, &'b str) -> &'a str;

If you've ever written

• a struct method
• a function which takes references
• a function which returns references
• a generic function
• a trait object (more on this later)
• a closure (more on this later)

then your code has generic elided lifetime annotations all over it.

如果你曾寫過

• struct 方法
• 獲取引用的函數(shù)
• 返回引用的函數(shù)
• 泛型函數(shù)
• trait 對象（稍后詳述）
• 閉包（稍后詳述）

那么你的代碼中就遍布省略的泛型生命周期注解。

Key Takeaways

• almost all Rust code is generic code and there's elided lifetime annotations everywhere

主要收獲

• 幾乎所有 Rust 代碼都是泛型代碼，四處皆是省略的生命周期注解

5) if it compiles then my lifetime annotations are correct

（只要編譯成功，生命周期注解就是正確的）

Misconception Corollaries

• Rust's lifetime elision rules for functions are always right
• Rust's borrow checker is always right, technically and semantically
• Rust knows more about the semantics of my program than I do

誤區(qū)延伸

• Rust 的函數(shù)生命周期省略規(guī)則總是正確的
• Rust 的借用檢查器在技術(shù)上和 語義上 總是正確的
• Rust 比我更了解程序的語義

It's possible for a Rust program to be technically compilable but still semantically wrong. Take this for example:

Rust 程序有可能在技術(shù)上可以編譯，但在語義上仍然是錯誤的。舉個(gè)例子：

struct ByteIter<'a> {
    remainder: &'a [u8]
}

impl<'a> ByteIter<'a> {
    fn next(&mut self) -> Option<&u8> {
        if self.remainder.is_empty() {
            None
        } else {
            let byte = &self.remainder[0];
            self.remainder = &self.remainder[1..];
            Some(byte)
        }
    }
}

fn main() {
    let mut bytes = ByteIter { remainder: b"1" };
    assert_eq!(Some(&b'1'), bytes.next());
    assert_eq!(None, bytes.next());
}

ByteIter is an iterator that iterates over a slice of bytes. We're skipping the Iterator trait implementation for conciseness. It seems to work fine, but what if we want to check a couple bytes at a time?

ByteIter 是一個(gè)用來迭代字節(jié)切片的迭代器。為了簡潔起見，我們跳過了 Iterator trait 的實(shí)現(xiàn)。目前一切正常，但如果我們想同時(shí)查看一對字節(jié)呢？

fn main() {
    let mut bytes = ByteIter { remainder: b"1123" };
    let byte_1 = bytes.next();
    let byte_2 = bytes.next();
    if byte_1 == byte_2 { // ?
        // do something
    }
}

Uh oh! Compile error:

呦！編譯錯誤：

error[E0499]: cannot borrow `bytes` as mutable more than once at a time
  --> src/main.rs:20:18
   |
19 |     let byte_1 = bytes.next();
   |                  ----- first mutable borrow occurs here
20 |     let byte_2 = bytes.next();
   |                  ^^^^^ second mutable borrow occurs here
21 |     if byte_1 == byte_2 {
   |        ------ first borrow later used here

I guess we can copy each byte. Copying is okay when we're working with bytes but if we turned ByteIter into a generic slice iterator that can iterate over any &'a [T] then we might want to use it in the future with types that may be very expensive or impossible to copy and clone. Oh well, I guess there's nothing we can do about that, the code compiles so the lifetime annotations must be right, right?

可以逐個(gè)復(fù)制字節(jié)來解決此編譯錯誤。確實(shí)，在處理字節(jié)時(shí)復(fù)制是沒問題的，但如果打算把 ByteIter 做成一個(gè)通用的切片迭代器，可以遍歷任何 &'a [T]，那就有可能把它用在復(fù)制或克隆成本很高的類型上，甚至是不可能復(fù)制或克隆的類型上。好吧，我想咱們對此都無能為力，代碼能編譯，那么生命周期注解一定是正確的，對嗎？

Nope, the current lifetime annotations are actually the source of the bug! It's particularly hard to spot because the buggy lifetime annotations are elided. Let's expand the elided lifetimes to get a clearer look at the problem:

不對，當(dāng)前的生命周期注解實(shí)際上正是 bug 的根源！該 bug 特別難以發(fā)現(xiàn)，因?yàn)殄e誤的生命周期注釋被省略掉了。我們來補(bǔ)充上被省略的生命周期，以便更清楚地了解問題所在：

struct ByteIter<'a> {
    remainder: &'a [u8]
}
impl<'a> ByteIter<'a> {
    fn next<'b>(&'b mut self) -> Option<&'b u8> {
        if self.remainder.is_empty() {
            None
        } else {
            let byte = &self.remainder[0];
            self.remainder = &self.remainder[1..];
            Some(byte)
        }
    }
}

That didn't help at all. I'm still confused. Here's a hot tip that only Rust pros know: give your lifetime annotations descriptive names. Let's try again:

一點(diǎn)幫助都沒有，看起來還是一頭霧水。此處有個(gè)只有 Rust 高手才知道的小竅門：給生命周期注解起個(gè)有意義的名字。來，再試一次：

struct ByteIter<'remainder> {
    remainder: &'remainder [u8]
}
impl<'remainder> ByteIter<'remainder> {
    fn next<'mut_self>(&'mut_self mut self) -> Option<&'mut_self u8> {
        if self.remainder.is_empty() {
            None
        } else {
            let byte = &self.remainder[0];
            self.remainder = &self.remainder[1..];
            Some(byte)
        }
    }
}

Each returned byte is annotated with 'mut_self but the bytes are clearly coming from 'remainder! Let's fix it.

每個(gè)返回的字節(jié)都被注解為 'mut_self，但這些字節(jié)顯然來自 'remainder ！來，搞定它。

struct ByteIter<'remainder> {
    remainder: &'remainder [u8]
}
impl<'remainder> ByteIter<'remainder> {
    fn next(&mut self) -> Option<&'remainder u8> {
        if self.remainder.is_empty() {
            None
        } else {
            let byte = &self.remainder[0];
            self.remainder = &self.remainder[1..];
            Some(byte)
        }
    }
}
fn main() {
    let mut bytes = ByteIter { remainder: b"1123" };
    let byte_1 = bytes.next();
    let byte_2 = bytes.next();
    // we can even drop the iterator now!
    // 調(diào)整后甚至可以 drop 掉迭代器
    std::mem::drop(bytes);
    if byte_1 == byte_2 { // ?
        // do something
    }
}

Now that we look back on the previous version of our program it was obviously wrong, so why did Rust compile it? The answer is simple: it was memory safe.

現(xiàn)在回過頭來看看上一個(gè)版本的代碼，既然它是錯誤的，Rust 為什么要編譯它呢？原因很簡單：它是內(nèi)存安全的。

The Rust borrow checker only cares about the lifetime annotations in a program to the extent it can use them to statically verify the memory safety of the program. Rust will happily compile programs even if the lifetime annotations have semantic errors, and the consequence of this is that the program becomes unnecessarily restrictive.

Rust 借用檢查器只要能利用生命周期注解靜態(tài)驗(yàn)證程序的內(nèi)存安全性就夠了，多余的事情不再關(guān)心。即使生命周期注解存在語義錯誤，Rust 也樂于編譯它，哪怕會給程序帶來不必要的限制。

Here's a quick example that's the opposite of the previous example: Rust's lifetime elision rules happen to be semantically correct in this instance but we unintentionally write a very restrictive method with our own unnecessary explicit lifetime annotations.

來看一個(gè)與上面相反的例子：示例中，Rust 的生命周期省略規(guī)則語義上正確，但我們卻無意中寫出了一個(gè)限制極嚴(yán)的方法，并使用了不必要的顯式生命周期注解。

#[derive(Debug)]
struct NumRef<'a>(&'a i32);
impl<'a> NumRef<'a> {
    // my struct is generic over 'a so that means I need to annotate
    // my self parameters with 'a too, right? (answer: no, not right)
    // 結(jié)構(gòu)體的泛型是 'a ，是否意味著
    // 也需要用 'a 來注解 self 參數(shù)？(答案：否）
    fn some_method(&'a mut self) {}
}
fn main() {
    let mut num_ref = NumRef(&5);
    // mutably borrows num_ref for the rest of its lifetime
    // 在其生命周期內(nèi)可變地借用 num_ref
    num_ref.some_method();
    num_ref.some_method(); // ?
    println!("{:?}", num_ref); // ?
}

If we have some struct generic over 'a we almost never want to write a method with a &'a mut self receiver. What we're communicating to Rust is _"this method will mutably borrow the struct for the entirety of the struct's lifetime"_. In practice this means Rust's borrow checker will only allow at most one call to some_method before the struct becomes permanently mutably borrowed and thus unusable. The use-cases for this are extremely rare but the code above is very easy for confused beginners to write and it compiles. The fix is to not add unnecessary explicit lifetime annotations and let Rust's lifetime elision rules handle it:

當(dāng) struct 存在泛型參數(shù) 'a 時(shí)，幾乎永遠(yuǎn)不會再寫一個(gè)接收 &'a mut self 的方法，因?yàn)檫@樣寫相當(dāng)于告訴 Rust _"該方法將在 struct 的整個(gè)生命周期內(nèi)可變地借用該 struct"_。實(shí)踐中意味著 Rust 的借用檢查器最多只允許調(diào)用 some_method 一次，之后 struct 就永久地被可變借用走，從而無法再使用。這種使用場景極其罕見，但對于懵懂的初學(xué)者來說，卻非常容易編寫出上面這類代碼，關(guān)鍵它還能編譯通過。解決方法是不去添加不必要的顯式生命周期注解，交由 Rust 的生命周期省略規(guī)則處理：

#[derive(Debug)]
struct NumRef<'a>(&'a i32);
impl<'a> NumRef<'a> {
    // no more 'a on mut self
    // mut self 上不再使用 'a
    fn some_method(&mut self) {}
    // above line desugars to
    // 去掉語法糖后相當(dāng)于
    fn some_method_desugared<'b>(&'b mut self){}
}
fn main() {
    let mut num_ref = NumRef(&5);
    num_ref.some_method();
    num_ref.some_method(); // ?
    println!("{:?}", num_ref); // ?
}

Key Takeaways

• Rust's lifetime elision rules for functions are not always right for every situation
• Rust does not know more about the semantics of your program than you do
• give your lifetime annotations descriptive names
• try to be mindful of where you place explicit lifetime annotations and why

主要收獲

• Rust 的函數(shù)生命周期省略規(guī)則并不總是適用于所有情況
• Rust 并不比你更了解程序的語義
• 為生命周期注解賦予有意義的名稱
• 謹(jǐn)慎考慮在何處放置顯式生命周期注解以及為什么要這樣做

6) boxed trait objects don't have lifetimes

（裝箱后的 trait 對象沒有生命周期）

Earlier we discussed Rust's lifetime elision rules _for functions_. Rust also has lifetime elision rules for trait objects, which are:

• if a trait object is used as a type argument to a generic type then its life bound is inferred from the containing type

  • if there's a unique bound from the containing then that's used
  • if there's more than one bound from the containing type then an explicit bound must be specified

• if the above doesn't apply then

  • if the trait is defined with a single lifetime bound then that bound is used
  • if 'static is used for any lifetime bound then 'static is used
  • if the trait has no lifetime bounds then its lifetime is inferred in expressions and is 'static outside of expressions

前面我們討論了 Rust 針對函數(shù)的生命周期省略規(guī)則。Rust 也有針對 trait 對象的生命周期省略規(guī)則，它們是：

• 如果 trait 對象被用作泛型的類型參數(shù)，那么它的生命周期約束從包含類型中推斷

  • 如果在包含類型中存在唯一一個(gè)約束，則使用該約束
  • 如果在包含類型中存在多個(gè)約束，則必須指定顯式約束

• 如果上述情況不適用，則

  • 如果 trait 的定義只有一個(gè)生命周期約束，則使用該約束
  • 如果 'static 被用于任何生命周期約束，則使用 'static
  • 如果 trait 沒有生命周期約束，則在表達(dá)式中推斷生命周期，并在表達(dá)式外使用 'static

All of that sounds super complicated but can be simply summarized as "a trait object's lifetime bound is inferred from context." After looking at a handful of examples we'll see the lifetime bound inferences are pretty intuitive so we don't have to memorize the formal rules:

這些聽起來超復(fù)雜，但可以簡單概括為 "根據(jù)上下文推斷出 trait 對象的生命周期約束" 。看幾個(gè)例子后你就會發(fā)現(xiàn)，生命周期約束推斷非常直觀，根本不必記住正式的規(guī)則：

use std::cell::Ref;
trait Trait {}
// elided 省略形式
type T1 = Box<dyn Trait>;
// expanded, Box<T> has no lifetime bound on T, so inferred as 'static
// 完整形式，Box<T> 對 T 沒有生命周期約束，因此推斷為 'static
type T2 = Box<dyn Trait + 'static>;
// elided 省略形式
impl dyn Trait {}
// expanded 完整形式
impl dyn Trait + 'static {}
// elided 省略形式
type T3<'a> = &'a dyn Trait;
// expanded, &'a T requires T: 'a, so inferred as 'a
// 完整形式，&'a T 要求 T: 'a，因此推斷為 'a
type T4<'a> = &'a (dyn Trait + 'a);
// elided 省略形式
type T5<'a> = Ref<'a, dyn Trait>;
// expanded, Ref<'a, T> requires T: 'a, so inferred as 'a
type T6<'a> = Ref<'a, dyn Trait + 'a>;
trait GenericTrait<'a>: 'a {}
// elided 省略形式
type T7<'a> = Box<dyn GenericTrait<'a>>;
// expanded 完整形式
type T8<'a> = Box<dyn GenericTrait<'a> + 'a>;
// elided 省略形式
impl<'a> dyn GenericTrait<'a> {}
// expanded 完整形式
impl<'a> dyn GenericTrait<'a> + 'a {}

Concrete types which implement traits can have references and thus they also have lifetime bounds, and so their corresponding trait objects have lifetime bounds. Also you can implement traits directly for references which obviously have lifetime bounds:

實(shí)現(xiàn)了 trait 的具體類型可以包含引用，因此它們也有生命周期約束，繼而它們對應(yīng)的 trait 對象也有生命周期約束。此外，還可以直接為引用實(shí)現(xiàn) trait，而引用顯然也有生命周期約束：

trait Trait {}
struct Struct {}
struct Ref<'a, T>(&'a T);
impl Trait for Struct {}
// impl Trait directly on a ref type
// 在引用類型上直接實(shí)現(xiàn) Trait
impl Trait for &Struct {}
// impl Trait on a type containing refs
// 在包含引用的類型上實(shí)現(xiàn) Trait
impl<'a, T> Trait for Ref<'a, T> {}

Anyway, this is worth going over because it often confuses beginners when they refactor a function from using trait objects to generics or vice versa. Take this program for example:

總之，這點(diǎn)很值得強(qiáng)調(diào)，因?yàn)槌鯇W(xué)者將函數(shù)從使用 trait 對象重構(gòu)為使用泛型（或反之）時(shí)，經(jīng)常會感到困惑。以此程序?yàn)槔?/p>

use std::fmt::Display;
fn dynamic_thread_print(t: Box<dyn Display + Send>) {
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}
fn static_thread_print<T: Display + Send>(t: T) { // ?
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}

It throws this compile error:

程序拋出編譯錯誤：

error[E0310]: the parameter type `T` may not live long enough
  --> src/lib.rs:10:5
   |
9  | fn static_thread_print<T: Display + Send>(t: T) {
   |                        -- help: consider adding an explicit lifetime bound...: `T: 'static +`
10 |     std::thread::spawn(move || {
   |     ^^^^^^^^^^^^^^^^^^
   |
note: ...so that the type `[closure@src/lib.rs:10:24: 12:6 t:T]` will meet its required lifetime bounds
  --> src/lib.rs:10:5
   |
10 |     std::thread::spawn(move || {
   |     ^^^^^^^^^^^^^^^^^^

Okay great, the compiler tells us how to fix the issue so let's fix the issue.

好極了，編譯器告知了如何解決問題，那就按它說的來解決一下吧。

use std::fmt::Display;

fn dynamic_thread_print(t: Box<dyn Display + Send>) {
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}

fn static_thread_print<T: Display + Send + 'static>(t: T) { // ?
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}

It compiles now but these two functions look awkward next to each other, why does the second function require a 'static bound on T where the first function doesn't? That's a trick question. Using the lifetime elision rules Rust automatically infers a 'static bound in the first function so both actually have 'static bounds. This is what the Rust compiler sees:

現(xiàn)在可以編譯了，但這兩個(gè)函數(shù)放在一起看時(shí)會很別扭：為什么第二個(gè)函數(shù)需要對 T 進(jìn)行 'static 約束，而第一個(gè)函數(shù)不需要呢？令人迷惑。其實(shí) Rust 使用生命周期省略規(guī)則自動在第一個(gè)函數(shù)中推斷出了 'static 約束，因此這兩個(gè)函數(shù)實(shí)際上都有 'static 約束。下面才是 Rust 編譯器看到的：

use std::fmt::Display;

fn dynamic_thread_print(t: Box<dyn Display + Send + 'static>) {
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}

fn static_thread_print<T: Display + Send + 'static>(t: T) {
    std::thread::spawn(move || {
        println!("{}", t);
    }).join();
}

Key Takeaways

• all trait objects have some inferred default lifetime bounds

主要收獲

• 所有 trait 對象都有隱含的默認(rèn)生命周期約束

7) compiler error messages will tell me how to fix my program

（編譯器的錯誤信息足以指導(dǎo)修復(fù)程序）

Misconception Corollaries

• Rust's lifetime elision rules for trait objects are always right
• Rust knows more about the semantics of my program than I do

誤區(qū)延伸

• Rust 針對 trait 對象的生命周期省略規(guī)則總是正確的
• Rust 比我更了解程序的語義

This misconception is the previous two misconceptions combined into one example:

這一誤區(qū)剛好是將前兩個(gè)合二為一的范例：

use std::fmt::Display;
fn box_displayable<T: Display>(t: T) -> Box<dyn Display> { // ?
    Box::new(t)
}

Throws this error:

拋出錯誤：

error[E0310]: the parameter type `T` may not live long enough
 --> src/lib.rs:4:5
  |
3 | fn box_displayable<T: Display>(t: T) -> Box<dyn Display> {
  |                    -- help: consider adding an explicit lifetime bound...: `T: 'static +`
4 |     Box::new(t)
  |     ^^^^^^^^^^^
  |
note: ...so that the type `T` will meet its required lifetime bounds
 --> src/lib.rs:4:5
  |
4 |     Box::new(t)
  |     ^^^^^^^^^^^

Okay, let's fix it how the compiler is telling us to fix it, nevermind the fact that it's automatically inferring a 'static lifetime bound for our boxed trait object without telling us and its recommended fix is based on that unstated fact:

好，我們來按照編譯器說的方式修復(fù)該問題，別忘了它自動為裝箱后的 trait 對象推斷出了 'static 生命周期約束，而編譯器推薦的解決方式正是基于這一未說明的事實(shí)：

use std::fmt::Display;

fn box_displayable<T: Display + 'static>(t: T) -> Box<dyn Display> { // ?
    Box::new(t)
}

So the program compiles now... but is this what we actually want? Probably, but maybe not. The compiler didn't mention any other fixes but this would have also been appropriate:

程序現(xiàn)在可以編譯了...但這就是我們想要的嗎？也許是，也許不是。編譯器沒有提到其他修復(fù)方式，但這樣其實(shí)也可以：

use std::fmt::Display;

fn box_displayable<'a, T: Display + 'a>(t: T) -> Box<dyn Display + 'a> { // ?
    Box::new(t)
}

This function accepts all the same arguments as the previous version plus a lot more! Does that make it better? Not necessarily, it depends on the requirements and constraints of our program. This example is a bit abstract so let's take a look at a simpler and more obvious case:

該函數(shù)不僅兼容前一版本的所有參數(shù)，還能接受更多參數(shù)！然而這樣就更好嗎？也不一定，這取決于程序的要求和限制。該例略為抽象，再來看個(gè)更簡單、更明顯的例子：

fn return_first(a: &str, b: &str) -> &str { // ?
    a
}

Throws:

拋出：

error[E0106]: missing lifetime specifier
 --> src/lib.rs:1:38
  |
1 | fn return_first(a: &str, b: &str) -> &str {
  |                    ----     ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
  |
1 | fn return_first<'a>(a: &'a str, b: &'a str) -> &'a str {
  |                ^^^^    ^^^^^^^     ^^^^^^^     ^^^

The error message recommends annotating both inputs and the output with the same lifetime. If we did this our program would compile but this function would overly-constrain the return type. What we actually want is this:

錯誤信息建議將輸入、輸出標(biāo)注為相同的生命周期。如果按它說的做，程序確實(shí)可以編譯，但該函數(shù)會過度約束返回類型。實(shí)際上，我們想要的是：

fn return_first<'a>(a: &'a str, b: &str) -> &'a str { // ?
    a
}

Key Takeaways

• Rust's lifetime elision rules for trait objects are not always right for every situation
• Rust does not know more about the semantics of your program than you do
• Rust compiler error messages suggest fixes which will make your program compile which is not that same as fixes which will make you program compile and best suit the requirements of your program

主要收獲

• Rust 針對 trait 對象的生命周期省略規(guī)則并非適合每種情況
• Rust 不會比你更了解程序的語義
• Rust 編譯器錯誤信息所建議的修復(fù)方法可以使程序編譯成功，但這并不等同于可以使程序編譯成功 并且 最符合要求。

8) lifetimes can grow and shrink at run-time

（生命周期可以在運(yùn)行期增長或縮短）

Misconception Corollaries

• container types can swap references at run-time to change their lifetime
• Rust borrow checker does advanced control flow analysis

誤區(qū)延伸

• 容器類型可在運(yùn)行期交換引用以改變其生命周期
• Rust 借用檢查器可進(jìn)行高級控制流分析

This does not compile:

以下代碼無法編譯：

struct Has<'lifetime> {
    lifetime: &'lifetime str,
}
fn main() {
    let long = String::from("long");
    let mut has = Has { lifetime: &long };
    assert_eq!(has.lifetime, "long");
    {
        let short = String::from("short");
        // "switch" to short lifetime
        // “切換”到 short 生命周期
        has.lifetime = &short;
        assert_eq!(has.lifetime, "short");
        // "switch back" to long lifetime (but not really)
        // “切換回” long 生命周期（其實(shí)并沒有）
        has.lifetime = &long;
        assert_eq!(has.lifetime, "long");
        // `short` dropped here
        // `short` 在此處被 drop
    }
    // ? - `short` still "borrowed" after drop
    // ? - `short` 在 drop 后仍處于 “借用” 狀態(tài)
    assert_eq!(has.lifetime, "long"); 
}

It throws:

它會拋出：

error[E0597]: `short` does not live long enough
  --> src/main.rs:11:24
   |
11 |         has.lifetime = &short;
   |                        ^^^^^^ borrowed value does not live long enough
...
15 |     }
   |     - `short` dropped here while still borrowed
16 |     assert_eq!(has.lifetime, "long");
   |     --------------------------------- borrow later used here

This also does not compile, throws the exact same error as above:

改成下面這樣也無法編譯，它會拋出與上面完全相同的錯誤：

struct Has<'lifetime> {
    lifetime: &'lifetime str,
}

fn main() {
    let long = String::from("long");
    let mut has = Has { lifetime: &long };
    assert_eq!(has.lifetime, "long");

    // this block will never run
    // 該代碼塊不會執(zhí)行
    if false {
        let short = String::from("short");
        // "switch" to short lifetime
        // “切換”到 short 生命周期
        has.lifetime = &short;
        assert_eq!(has.lifetime, "short");

        // "switch back" to long lifetime (but not really)
        // “切換回” long 生命周期（其實(shí)并沒有）
        has.lifetime = &long;
        assert_eq!(has.lifetime, "long");
        // `short` dropped here
        // `short` 在此處被 drop
    }
    // ? - `short` still "borrowed" after drop
    // ? - `short` 在 drop 后仍處于 “借用” 狀態(tài)
    assert_eq!(has.lifetime, "long"); 
}

Lifetimes have to be statically verified at compile-time and the Rust borrow checker only does very basic control flow analysis, so it assumes every block in an if-else statement and every match arm in a match statement can be taken and then chooses the shortest possible lifetime for the variable. Once a variable is bounded by a lifetime it is bounded by that lifetime _forever_. The lifetime of a variable can only shrink, and all the shrinkage is determined at compile-time.

生命周期必須在編譯期進(jìn)行靜態(tài)驗(yàn)證，而 Rust 借用檢查器也只能進(jìn)行非?；A(chǔ)的控制流分析，因此它假定 if-else 語句和 match 語句中的每個(gè)分支代碼塊都將被執(zhí)行[譯注：Rust 編譯器采用了流敏感分析(flow-sensitive analyses)]，然后為變量選擇最短的生命周期。變量的生命周期一旦被確定，就會永遠(yuǎn)受該生命周期約束。變量的生命周期只能縮短，而所有的縮短都會在編譯期決定。

Key Takeaways

• lifetimes are statically verified at compile-time
• lifetimes cannot grow or shrink or change in any way at run-time
• Rust borrow checker will always choose the shortest possible lifetime for a variable assuming all code paths can be taken

主要收獲

• 生命周期在編譯期進(jìn)行靜態(tài)驗(yàn)證
• 生命周期不能在運(yùn)行期以任何方式增長、縮短或改變
• Rust 借用檢查器總是假定所有代碼路徑都會被執(zhí)行，然后為變量選擇最短的生命周期

9) downgrading mut refs to shared refs is safe

（將可變引用降級為共享引用是安全操作）

Misconception Corollaries

• re-borrowing a reference ends its lifetime and starts a new one

誤區(qū)延伸

• 重新借用引用會結(jié)束其原有生命周期，并開始新的生命周期

You can pass a mut ref to a function expecting a shared ref because Rust will implicitly re-borrow the mut ref as immutable:

可以將可變引用傳遞給期望使用共享引用的函數(shù)，Rust 會隱式地重新借用可變引用，并將其視為不可變：

fn takes_shared_ref(n: &i32) {}

fn main() {
    let mut a = 10;
    takes_shared_ref(&mut a); // ?
    takes_shared_ref(&*(&mut a)); // above line desugared 上行代碼去掉語法糖后
}

Intuitively this makes sense, since there's no harm in re-borrowing a mut ref as immutable, right? Surprisingly no, as the program below does not compile:

直覺上這也沒問題，畢竟重新借用一個(gè)可變引用并將其視為不可變的，沒什么毛病，對吧？令人驚訝的是，情況并非如此，下面的程序無法編譯：

fn main() {
    let mut a = 10;
    let b: &i32 = &*(&mut a); // re-borrowed as immutable 重新借用為不可變引用
    let c: &i32 = &a;
    dbg!(b, c); // ?
}

Throws this error:

拋出錯誤：

error[E0502]: cannot borrow `a` as immutable because it is also borrowed as mutable
 --> src/main.rs:4:19
  |
3 |     let b: &i32 = &*(&mut a);
  |                     -------- mutable borrow occurs here
4 |     let c: &i32 = &a;
  |                   ^^ immutable borrow occurs here
5 |     dbg!(b, c);
  |          - mutable borrow later used here

A mutable borrow does occur, but it's immediately and unconditionally re-borrowed as immutable and then dropped. Why is Rust treating the immutable re-borrow as if it still has the mut ref's exclusive lifetime? While there's no issue in the particular example above, allowing the ability to downgrade mut refs to shared refs does indeed introduce potential memory safety issues:

可變借用確實(shí)發(fā)生了，但它會被立即無條件地重新借用為不可變的，繼而被 drop 掉。為什么 Rust 會把“不可變的重新借用”視作“仍具有可變引用”的獨(dú)占生命周期呢？上例雖沒有問題，但允許將可變引用降級為共享引用確實(shí)會帶來潛在的內(nèi)存安全問題：

use std::sync::Mutex;
struct Struct {
    mutex: Mutex<String>
}
impl Struct {
    // downgrades mut self to shared str
    // 將可變引用 self 降級為共享引用 str
    fn get_string(&mut self) -> &str {
        self.mutex.get_mut().unwrap()
    }
    fn mutate_string(&self) {
        // if Rust allowed downgrading mut refs to shared refs
        // then the following line would invalidate any shared
        // refs returned from the get_string method
        // 如果 Rust 允許將可變引用降級為共享引用，那么下面一行
        // 將使 get_string 方法返回的任何共享引用都失效
        *self.mutex.lock().unwrap() = "surprise!".to_owned();
    }
}
fn main() {
    let mut s = Struct {
        mutex: Mutex::new("string".to_owned())
    };
    // mut ref downgraded to shared ref 
    // 可變引用降級為共享引用
    let str_ref = s.get_string(); 
    // str_ref invalidated, now a dangling pointer
    // str_ref 已失效，成了個(gè)懸垂指針
    s.mutate_string(); 
    dbg!(str_ref); // ? - as expected! 一如所料！
}

The point here is that when you re-borrow a mut ref as a shared ref you don't get that shared ref without a big gotcha: it extends the mut ref's lifetime for the duration of the re-borrow even if the mut ref itself is dropped. Using the re-borrowed shared ref is very difficult because it's immutable but it can't overlap with any other shared refs. The re-borrowed shared ref has all the cons of a mut ref and all the cons of a shared ref and has the pros of neither. I believe re-borrowing a mut ref as a shared ref should be considered a Rust anti-pattern. Being aware of this anti-pattern is important so that you can easily spot it when you see code like this:

這里的重點(diǎn)是，重新將可變引用借用為共享引用，并不能順利地獲得共享引用：即使可變引用本身已被 drop，它也會在重新借用期間延長可變引用的生命周期。使用重新借用的共享引用非常困難，盡管它是不可變的，但它不能與任何其他共享引用重疊（譯注：即，不能與其他引用同時(shí)訪問相同的資源）。重新借用的共享引用既有可變引用的所有缺點(diǎn)，也有共享引用的所有缺點(diǎn)，而且還不具備兩者的優(yōu)點(diǎn)。所以我認(rèn)為，“重新將可變引用借用為共享引用”應(yīng)被視為 Rust 的反模式。意識到這種反模式很重要，這樣當(dāng)你看到類似代碼時(shí)就能很快辨別它：

// downgrades mut T to shared T
// 將可變引用 T 降級為共享引用 T
fn some_function<T>(some_arg: &mut T) -> &T;
struct Struct;
impl Struct {
    // downgrades mut self to shared self
    // 將可變引用 self 降級為共享引用 self
    fn some_method(&mut self) -> &Self;
    // downgrades mut self to shared T
    // 將可變引用 self 降級為共享引用 T
    fn other_method(&mut self) -> &T;
}

Even if you avoid re-borrows in function and method signatures Rust still does automatic implicit re-borrows so it's easy to bump into this problem without realizing it like so:

即便在函數(shù)或方法簽名中避免了重新借用，Rust 仍會自動進(jìn)行隱式的重新借用，因此很容易在不知情的情況下遇到問題，例如：

use std::collections::HashMap;
type PlayerID = i32;
#[derive(Debug, Default)]
struct Player {
    score: i32,
}
fn start_game(player_a: PlayerID, player_b: PlayerID, server: &mut HashMap<PlayerID, Player>) {
    // get players from server or create & insert new players if they don't yet exist
    // 從 server 獲取 player，若無，則創(chuàng)建并插入新 player
    let player_a: &Player = server.entry(player_a).or_default();
    let player_b: &Player = server.entry(player_b).or_default();
    // do something with players
    // 對 player 進(jìn)行某些操作
    dbg!(player_a, player_b); // ?
}

The above fails to compile. or_default() returns a &mut Player which we're implicitly re-borrowing as &Player because of our explicit type annotations. To do what we want we have to:

上述代碼編譯失敗。由于我們顯式地標(biāo)注了數(shù)據(jù)類型，Rust 會隱式地將 or_default() 返回的 &mut Player 重新借用為 &Player。為了達(dá)成目的，我們必須：

use std::collections::HashMap;
type PlayerID = i32;
#[derive(Debug, Default)]
struct Player {
    score: i32,
}
fn start_game(player_a: PlayerID, player_b: PlayerID, server: &mut HashMap<PlayerID, Player>) {
    // drop the returned mut Player refs since we can't use them together anyway
    // 丟棄所有返回的 Player 可變引用，反正也不能同時(shí)使用它們
    server.entry(player_a).or_default();
    server.entry(player_b).or_default();
    // fetch the players again, getting them immutably this time, without any implicit re-borrows
    // 這次以不可變方式再次獲取 player，而不會有任何隱式的重新借用。
    let player_a = server.get(&player_a);
    let player_b = server.get(&player_b);
    // do something with players
    // 對 player 進(jìn)行某些操作
    dbg!(player_a, player_b); // ?
}

Kinda awkward and clunky but this is the sacrifice we make at the Altar of Memory Safety.

雖然有些笨拙，而且不夠優(yōu)雅，但這是我們給“內(nèi)存安全祭壇”獻(xiàn)上的祭品。

Key Takeaways

• try not to re-borrow mut refs as shared refs, or you're gonna have a bad time
• re-borrowing a mut ref doesn't end its lifetime, even if the ref is dropped

主要收獲

• 盡量避免將可變引用重新借用為共享引用，否則會讓你頭大
• 重新借用可變引用不會結(jié)束其生命周期，即使該引用已被 drop 掉

10) closures follow the same lifetime elision rules as functions

（閉包遵循與函數(shù)相同的生命周期省略規(guī)則）

This is more of a Rust Gotcha than a misconception.

這條更像是 Rust 中的一個(gè)陷阱，而不是誤區(qū)。

Closures, despite being functions, do not follow the same lifetime elision rules as functions.

閉包，盡管也是函數(shù)，但并不遵循與函數(shù)相同的生命周期省略規(guī)則。

fn function(x: &i32) -> &i32 {
    x
}
fn main() {
    let closure = |x: &i32| x; // ?
}

Throws:

拋出:

error: lifetime may not live long enough
 --> src/main.rs:6:29
  |
6 |     let closure = |x: &i32| x;
  |                       -   - ^ returning this value requires that `'1` must outlive `'2`
  |                       |   |
  |                       |   return type of closure is &'2 i32
  |                       let's call the lifetime of this reference `'1`

After desugaring we get:

（將省略規(guī)則）展開后得到：

// input lifetime gets applied to output
// 輸入生命周期同時(shí)應(yīng)用于輸出
fn function<'a>(x: &'a i32) -> &'a i32 {
    x
}
fn main() {
    // input and output each get their own distinct lifetimes
    // 輸入和輸出各自具有獨(dú)立的生命周期
    let closure = for<'a, 'b> |x: &'a i32| -> &'b i32 { x };
    // note: the above line is not valid syntax, but we need it for illustrative purposes
    // 注意：上行不是有效的語法，只是用它來說明問題
}

There's no good reason for this discrepancy. Closures were first implemented with different type inference semantics than functions and now we're stuck with it forever because to unify them at this point would be a breaking change. So how can we explicitly annotate a closure's type? Our options include:

造成這種差異的原因挺荒謬的。閉包在最一開始時(shí)便使用了與函數(shù)不同的類型推斷語義，而現(xiàn)今我們永遠(yuǎn)都只能如此了，因?yàn)榇藭r(shí)再統(tǒng)一它們將是個(gè)不兼容的改變。那么該如何顯式標(biāo)注閉包的類型呢？可選項(xiàng)有：

fn main() {
    // cast to trait object, becomes unsized, oops, compile error
    // 轉(zhuǎn)換為 trait 對象，變成 unsized，呃，可能導(dǎo)致編譯錯誤
    let identity: dyn Fn(&i32) -> &i32 = |x: &i32| x;
    // can allocate it on the heap as a workaround but feels clunky
    // 可以將其分配到堆上，倒也算個(gè)笨方法
    let identity: Box<dyn Fn(&i32) -> &i32> = Box::new(|x: &i32| x);
    // can skip the allocation and just create a static reference
    // 可以跳過分配過程，直接創(chuàng)建一個(gè)靜態(tài)引用
    let identity: &dyn Fn(&i32) -> &i32 = &|x: &i32| x;
    // previous line desugared :)
    // 將上一行展開 :)
    let identity: &'static (dyn for<'a> Fn(&'a i32) -> &'a i32 + 'static) = &|x: &i32| -> &i32 { x };
    // this would be ideal but it's invalid syntax
    // 這樣做似乎更理想，但它是無效語法
    let identity: impl Fn(&i32) -> &i32 = |x: &i32| x;
    // this would also be nice but it's also invalid syntax
    // 這樣做也很好，但同樣是無效語法
    let identity = for<'a> |x: &'a i32| -> &'a i32 { x };
    // since "impl trait" works in the function return position
    // 鑒于 "impl trait" 在函數(shù)返回值處有效
    fn return_identity() -> impl Fn(&i32) -> &i32 {
        |x| x
    }
    let identity = return_identity();
    // more generic version of the previous solution
    // 前一解決方案更通用的版本
    fn annotate<T, F>(f: F) -> F where F: Fn(&T) -> &T {
        f
    }
    let identity = annotate(|x: &i32| x);
}

As I'm sure you've already noticed from the examples above, when closure types are used as trait bounds they do follow the usual function lifetime elision rules.

從上面的示例中可以看出，當(dāng)閉包類型用作 trait 約束時(shí)，它們確實(shí)遵循常規(guī)的函數(shù)生命周期省略規(guī)則。

There's no real lesson or insight to be had here, it just is what it is.

關(guān)于這一條沒有什么經(jīng)驗(yàn)教訓(xùn)或啟示了，事情就是這樣。

Key Takeaways

• every language has gotchas ??

主要收獲

• 每種語言皆有陷阱 ??

Conclusion（結(jié)論）

• T is a superset of both &T and &mut T
• &T and &mut T are disjoint sets
• T: 'static should be read as "T is bounded by a 'static lifetime"
• if T: 'static then T can be a borrowed type with a 'static lifetime or an owned type

• since T: 'static includes owned types that means T

  • can be dynamically allocated at run-time
  • does not have to be valid for the entire program
  • can be safely and freely mutated
  • can be dynamically dropped at run-time
  • can have lifetimes of different durations
• T: 'a is more general and more flexible than &'a T
• T: 'a accepts owned types, owned types which contain references, and references
• &'a T only accepts references
• if T: 'static then T: 'a since 'static >= 'a for all 'a
• almost all Rust code is generic code and there's elided lifetime annotations everywhere
• Rust's lifetime elision rules are not always right for every situation
• Rust does not know more about the semantics of your program than you do
• give your lifetime annotations descriptive names
• try to be mindful of where you place explicit lifetime annotations and why
• all trait objects have some inferred default lifetime bounds
• Rust compiler error messages suggest fixes which will make your program compile which is not that same as fixes which will make you program compile and best suit the requirements of your program
• lifetimes are statically verified at compile-time
• lifetimes cannot grow or shrink or change in any way at run-time
• Rust borrow checker will always choose the shortest possible lifetime for a variable assuming all code paths can be taken
• try not to re-borrow mut refs as shared refs, or you're gonna have a bad time
• re-borrowing a mut ref doesn't end its lifetime, even if the ref is dropped
• every language has gotchas ??
• T 是 &T 和 &mut T 的超集
• &T 和 &mut T 是互不相交的集合
• T: 'static 應(yīng)被理解為 “T 受 'static 生命周期約束”
• 若 T: 'static 則 T 可以是擁有 'static 生命周期的借用類型 或 擁有所有權(quán)的類型

• 既然 T: 'static 包括擁有所有權(quán)的類型，便意味著 T

  • 可以在運(yùn)行期動態(tài)分配
  • 不必在整個(gè)程序運(yùn)行期間有效
  • 可以安全、自由地修改
  • 可以在運(yùn)行期動態(tài) drop
  • 可以有不同的生命周期
• 與 &'a T 相比，T: 'a 更通用、更靈活
• T: 'a 接受擁有所有權(quán)的類型（其內(nèi)部可含有引用）、引用類型
• &'a T 只接受引用類型
• 若 T: 'static 則 T: 'a ，因?yàn)閷τ谒?nbsp;'a 都有 'static >= 'a
• 幾乎所有 Rust 代碼都是泛型代碼，四處皆是省略的生命周期注解
• Rust 的函數(shù)生命周期省略規(guī)則并不總是適用于所有情況
• Rust 并不比你更了解程序的語義
• 為生命周期注解賦予有意義的名稱
• 謹(jǐn)慎考慮在何處放置顯式生命周期注解以及為什么要這樣做
• 所有 trait 對象都有隱含的默認(rèn)生命周期約束
• Rust 針對 trait 對象的生命周期省略規(guī)則并非適合每種情況
• Rust 不會比你更了解程序的語義
• Rust 編譯器錯誤信息所建議的修復(fù)方法可以使程序編譯成功，但這并不等同于可以使程序編譯成功 并且 最符合要求。
• 生命周期在編譯期進(jìn)行靜態(tài)驗(yàn)證
• 生命周期不能在運(yùn)行期以任何方式增長、縮短或改變
• Rust 借用檢查器總是假定所有代碼路徑都會被執(zhí)行，然后為變量選擇最短的生命周期
• 盡量避免將可變引用重新借用為共享引用，否則會讓你頭大
• 重新借用可變引用不會結(jié)束其生命周期，即使該引用已被 drop 掉
• 每種語言皆有陷阱 ??

以上就是Rust生命周期常見誤區(qū)(中英對照)全面指南的詳細(xì)內(nèi)容，更多關(guān)于Rust生命周期的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論