blocks|key|2905303|text|注意，除了结构定义之外，这段代码中没有显式的生命周期。编译器完全能够推断main()中的生命周期。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2905304|然而，在类型定义中，显式生命周期是不可避免的。例如，这里有一个不明确的地方：|2905305|struct+RefPair(&u32,+&u32);|code-block|syntax|javascript|2905306|它们应该是不同的生命周期还是相同的生命周期？从使用的角度来看，这确实很重要，struct+RefPair<'a,+'b>(&'a+u32,+&'b+u32)与struct+RefPair<'a>(&'a+u32,+&'a+u32)有很大的不同。|2905307|现在，对于简单的情况，就像您提供的情况一样，理论上编译器可以像在其他地方一样进行elide+lifetimes，但这种情况非常有限，不值得在编译器中增加额外的复杂性，而且这种清晰度的提高至少是值得怀疑的。|2905308|entityMap|0|LINK|mutability|MUTABLE|url|https://doc.rust-lang.org/stable/book/second-edition/ch10-03-lifetime-syntax.html#lifetime-elision^0|10|6|0|0|0|12|14|27|10|0|14|F|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|18|8|@]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|Q|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

Note that there are no explicit lifetimes in that piece of code, except the structure definition. The compiler is perfectly able to infer lifetimes in <code>main()</code>.

In type definitions, however, explicit lifetimes are unavoidable. For example, there is an ambiguity here:

<pre><code>struct RefPair(&amp;u32, &amp;u32);
</code></pre>

Should these be different lifetimes or should they be the same? It does matter from the usage perspective, <code>struct RefPair&lt;'a, 'b&gt;(&amp;'a u32, &amp;'b u32)</code> is very different from <code>struct RefPair&lt;'a&gt;(&amp;'a u32, &amp;'a u32)</code>. 

Now, for simple cases, like the one you provided, the compiler could theoretically <a href="https://doc.rust-lang.org/stable/book/second-edition/ch10-03-lifetime-syntax.html#lifetime-elision" rel="nofollow noreferrer">elide lifetimes</a> like it does in other places, but such cases are very limited and do not worth extra complexity in the compiler, and this gain in clarity would be at the very least questionable.

blocks|key|2905310|text|让我们看一下下面的例子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2905311|fn+foo<'a,+'b>(x:+&'a+u32,+y:+&'b+u32)+->+&'a+u32+{
++++x
}

fn+main()+{
++++let+x+=+12;
++++let+z:+&u32+=+{
++++++++let+y+=+42;
++++++++foo(&x,+&y)
++++};
}|code-block|syntax|javascript|2905312|在这里，显式的生命周期很重要。这是因为foo的结果与它的第一个参数('a)具有相同的生命周期，所以它可能比第二个参数更长。这是由foo签名中的生命周期名称表示的。如果您将调用中的参数切换为foo，编译器将会抱怨y的生存时间不够长：|offset|length|style|CODE|2905313|error[E0597]:+`y`+does+not+live+long+enough
++-->+src/main.rs:10:5
+++%7C
9++%7C+++++++++foo(&y,+&x)
+++%7C++++++++++++++-+borrow+occurs+here
10+%7C+++++};
+++%7C+++++%5E+`y`+dropped+here+while+still+borrowed
11+%7C+}
+++%7C+-+borrowed+value+needs+to+live+until+here|2905314|entityMap^0|0|0|J|3|Y|2|1S|3|2M|3|2X|1|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]|$I|11|J|12|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$]]

Let's have a look at the following example.

<pre><code>fn foo&lt;'a, 'b&gt;(x: &amp;'a u32, y: &amp;'b u32) -&gt; &amp;'a u32 {
 x
}

fn main() {
 let x = 12;
 let z: &amp;u32 = {
 let y = 42;
 foo(&amp;x, &amp;y)
 };
}
</code></pre>

Here, the explicit lifetimes are important. This compiles because the result of <code>foo</code> has the same lifetime as its first argument (<code>'a</code>), so it may outlive its second argument. This is expressed by the lifetime names in the signature of <code>foo</code>. If you switched the arguments in the call to <code>foo</code> the compiler would complain that <code>y</code> does not live long enough:

<pre class="lang-none prettyprint-override"><code>error[E0597]: `y` does not live long enough
 --&gt; src/main.rs:10:5
 |
9 | foo(&amp;y, &amp;x)
 | - borrow occurs here
10 | };
 | ^ `y` dropped here while still borrowed
11 | }
 | - borrowed value needs to live until here
</code></pre>

blocks|key|129157|text|书中的案例在设计上非常简单。生命周期的主题被认为是复杂的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|129158|编译器不能轻易地推断具有多个参数的函数的生存期。|129159|另外，我自己的optional+crate有一个OptionBool类型和一个as_slice方法，该方法的签名实际上是：|offset|length|style|CODE|129160|fn+as_slice(&self)+->+&'static+[bool]+{+...+}|code-block|syntax|javascript|129161|编译器绝对不可能弄明白这一点。|129162|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/llogiq/optional^0|0|0|O|A|13|8|7|8|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@$F|11|G|12|H|I]|$F|13|G|14|H|I]]|9|@$F|15|G|16|1|17]]|A|$]]|$1|J|3|K|5|L|7|18|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

The case from the book is very simple by design. The topic of lifetimes is deemed complex.

The compiler cannot easily infer the lifetime in a function with multiple arguments. 

Also, my own <a href="https://github.com/llogiq/optional" rel="nofollow noreferrer">optional</a> crate has an <code>OptionBool</code> type with an <code>as_slice</code> method whose signature actually is:

<pre><code>fn as_slice(&amp;self) -&gt; &amp;'static [bool] { ... }
</code></pre>

There is absolutely no way the compiler could have figured that one out.

blocks|key|2905339|text|其他的答案都有显著的要点(fjh's+concrete+example+where+an+explicit+lifetime+is+needed)，但是缺少一个关键的东西:当编译器会告诉您错误的时候，为什么需要显式的生命周期|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2905340|这实际上和“当编译器可以推断出显式类型时为什么需要显式类型”是同一个问题。一个假设的例子：|2905341|fn+foo()+->+_+{++
++++""
}|code-block|syntax|javascript|2905342|当然，编译器可以看到我返回的是一个&'static+str，那么为什么程序员必须键入它呢？|style|CODE|2905343|主要原因是，虽然编译器可以看到您的代码做了什么，但它不知道您的意图是什么。|2905344|函数是防火墙的自然边界，不受代码更改的影响。如果我们允许从代码中完全检查生命周期，那么一个看起来无害的更改可能会影响生命周期，这可能会导致遥远的函数中出现错误。这不是一个假设的例子。据我所知，当你依赖顶级函数的类型推断时，Haskell就有这个问题。铁锈把那个特殊的问题扼杀在萌芽状态。|2905345|编译器还有一个效率优势--只需要解析函数签名就可以验证类型和生存期。更重要的是，它对程序员有效率上的好处。如果我们没有明确的生命周期，这个函数能做什么：|2905346|fn+foo(a:+&u8,+b:+&u8)+->+&u8|2905347|不检查源代码就无法判断，这与大量的编码最佳实践背道而驰。|2905348|通过推断对更大范围的引用的非法赋值进行|2905349|blockquote|2905350|2905351|2905352|从本质上讲，作用域是生命周期。更清楚的是，生命周期'a是一个通用的生命周期参数，它可以在编译时根据调用位置在特定范围内进行专门化。|2905353|2905354|是实际需要的显式生命周期，以防止...错误？|2905355|2905356|2905357|不用谢。需要生命周期来防止错误，但需要显式的生命周期来保护不太健全的程序员所拥有的。|2905358|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/31609892/924313^0|D|1N|0|0|0|0|H|C|0|0|0|0|0|0|0|0|0|0|P|2|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@$A|1M|B|1N|1|1O]]|C|$]]|$1|D|3|E|5|6|7|1P|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1Q|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1R|8|@$A|1S|B|1T|M|N]]|9|@]|C|$]]|$1|O|3|P|5|6|7|1U|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1V|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|1W|8|@]|9|@]|C|$]]|$1|U|3|V|5|H|7|1X|8|@]|9|@]|C|$I|J]]|$1|W|3|X|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|10|3|-4|5|11|7|20|8|@]|9|@]|C|$]]|$1|12|3|-4|5|6|7|21|8|@]|9|@]|C|$]]|$1|13|3|-4|5|6|7|22|8|@]|9|@]|C|$]]|$1|14|3|15|5|6|7|23|8|@$A|24|B|25|M|N]]|9|@]|C|$]]|$1|16|3|-4|5|6|7|26|8|@]|9|@]|C|$]]|$1|17|3|18|5|11|7|27|8|@]|9|@]|C|$]]|$1|19|3|-4|5|6|7|28|8|@]|9|@]|C|$]]|$1|1A|3|-4|5|6|7|29|8|@]|9|@]|C|$]]|$1|1B|3|1C|5|6|7|2A|8|@]|9|@]|C|$]]|$1|1D|3|-4|5|6|7|2B|8|@]|9|@]|C|$]]]|1E|$1F|$5|1G|1H|1I|C|$1J|1K]]]]

The other answers all have salient points (<a href="https://stackoverflow.com/a/31609892/924313">fjh's concrete example where an explicit lifetime is needed</a>), but are missing one key thing: why are explicit lifetimes needed when the compiler will tell you you've got them wrong?

This is actually the same question as "why are explicit types needed when the compiler can infer them". A hypothetical example:

<pre><code>fn foo() -&gt; _ { 
 ""
}
</code></pre>

Of course, the compiler can see that I'm returning a <code>&amp;'static str</code>, so why does the programmer have to type it?

The main reason is that while the compiler can see what your code does, it doesn't know what your intent was.

Functions are a natural boundary to firewall the effects of changing code. If we were to allow lifetimes to be completely inspected from the code, then an innocent-looking change might affect the lifetimes, which could then cause errors in a function far away. This isn't a hypothetical example. As I understand it, Haskell has this problem when you rely on type inference for top-level functions. Rust nipped that particular problem in the bud. 

There is also an efficiency benefit to the compiler — only function signatures need to be parsed in order to verify types and lifetimes. More importantly, it has an efficiency benefit for the programmer. If we didn't have explicit lifetimes, what does this function do:

<pre><code>fn foo(a: &amp;u8, b: &amp;u8) -&gt; &amp;u8
</code></pre>

It's impossible to tell without inspecting the source, which would go against a huge number of coding best practices.

<blockquote>
 by inferring an illegal assignment of a reference to a wider scope
</blockquote>

Scopes are lifetimes, essentially. A bit more clearly, a lifetime <code>'a</code> is a generic lifetime parameter that can be specialized with a specific scope at compile time, based on the call site. 

<blockquote>
 are explicit lifetimes actually needed to prevent [...] errors?
</blockquote>

Not at all. Lifetimes are needed to prevent errors, but explicit lifetimes are needed to protect what little sanity programmers have.

blocks|key|130132|text|以下结构中的生存期注释：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|130133|struct+Foo<'a>+{
++++x:+&'a+i32,
}|code-block|syntax|javascript|130134|指定Foo实例的生存期不应超过它所包含的引用(x字段)。|offset|length|style|CODE|130135|您在“生锈”一书中遇到的示例并没有说明这一点，因为f和y变量同时超出了范围。|130136|一个更好的例子是：|130137|fn+main()+{
++++let+f+:+Foo;
++++{
++++++++let+n+=+5;++//+variable+that+is+invalid+outside+this+block
++++++++let+y+=+&n;
++++++++f+=+Foo+{+x:+y+};
++++};
++++println!("{}",+f.x);
}|130138|现在，f确实比f.x所指向的变量存活得更久。|130139|entityMap^0|0|0|2|3|N|1|0|P|1|R|1|0|0|0|3|1|7|3|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@$I|Z|J|10|K|L]|$I|11|J|12|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@$I|14|J|15|K|L]|$I|16|J|17|K|L]]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1A|8|@$I|1B|J|1C|K|L]|$I|1D|J|1E|K|L]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|V|$]]

The lifetime annotation in the following structure:

<pre><code>struct Foo&lt;'a&gt; {
 x: &amp;'a i32,
}
</code></pre>

specifies that a <code>Foo</code> instance shouldn't outlive the reference it contains (<code>x</code> field).

The example you came across in the Rust book doesn't illustrate this because <code>f</code> and <code>y</code> variables go out of scope at the same time.

A better example would be this:

<pre><code>fn main() {
 let f : Foo;
 {
 let n = 5; // variable that is invalid outside this block
 let y = &amp;n;
 f = Foo { x: y };
 };
 println!("{}", f.x);
}
</code></pre>

Now, <code>f</code> really outlives the variable pointed to by <code>f.x</code>.

blocks|key|2693412|text|我在这里找到了另一个很好的解释：http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#returning-references。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2693413|2693414|通常，只有从过程的参数派生的引用才能返回。在这种情况下，指针结果将始终与其中一个参数具有相同的生存期；命名生存期指示哪个参数是。|blockquote|2693415|2693416|entityMap|0|LINK|mutability|MUTABLE|url|http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#returning-references^0|G|21|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

I've found another great explanation here: <a href="http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#returning-references" rel="nofollow">http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#returning-references</a>.

<blockquote>
 In general, it is only possible to return references if they are
 derived from a parameter to the procedure. In that case, the pointer
 result will always have the same lifetime as one of the parameters;
 named lifetimes indicate which parameter that is.
</blockquote>

blocks|key|2693418|text|如果一个函数接收两个引用作为参数并返回一个引用，那么函数的实现有时可能返回第一个引用，有时返回第二个引用。无法预测给定调用将返回哪个引用。在这种情况下，无法推断返回引用的生存期，因为每个参数引用可能引用具有不同生存期的不同变量绑定。明确的生命周期有助于避免或澄清这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2693419|同样，如果一个结构包含两个引用(作为两个成员字段)，那么该结构的成员函数有时会返回第一个引用，有时会返回第二个引用。再说一次，明确的生命周期可以防止这种模棱两可的情况。|2693420|在一些简单的情况下，编译器可以在中推断生命周期。|2693421|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If a function receives two references as arguments and returns a reference, then the implementation of the function might sometimes return the first reference and sometimes the second one. It is impossible to predict which reference will be returned for a given call. In this case, it is impossible to infer a lifetime for the returned reference, since each argument reference may refer to a different variable binding with a different lifetime. Explicit lifetimes help to avoid or clarify such a situation.

Likewise, if a structure holds two references (as two member fields) then a member function of the structure may sometimes return the first reference and sometimes the second one. Again explicit lifetimes prevent such ambiguities.

In a few simple situations, there is <a href="https://doc.rust-lang.org/stable/book/second-edition/ch10-03-lifetime-syntax.html#lifetime-elision" rel="nofollow noreferrer">lifetime elision</a> where the compiler can infer lifetimes.

blocks|key|2905367|text|您的示例不起作用的原因很简单，因为Rust只有本地生存期和类型推断。您提出的建议需要全局推理。每当有一个引用的生命周期不能被省略时，就必须对其进行注释。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2905368|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The reason why your example does not work is simply because Rust only has local lifetime and type inference. What you are suggesting demands global inference. Whenever you have a reference whose lifetime cannot be elided, it must be annotated.

blocks|key|129213|text|作为Rust的新手，我的理解是明确的生命周期有两个目的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|129214|129215|将显式生存期注释放在函数上会限制可能出现在该函数内部的代码类型。|ordered-list-item|129216|如果你(编译器)想要检查一段代码是否有效，你(编译器)就不必迭代地检查每个被调用的函数。看看这段代码直接调用的函数的注释就足够了。这使得您的程序更容易为您(编译器)推理，并使编译时间易于管理。|129217|129218|关于第1点，请考虑用Python编写的以下程序：|129219|import+pandas+as+pd
import+numpy+as+np

def+second_row(ar):
++++return+ar[0]

def+work(second):
++++df+=+pd.DataFrame(data=second)
++++df.loc[0,+0]+=+1

def+main():
++++#+..+load+data+..
++++ar+=+np.array([[0,+0],+[0,+0]])

++++#+..+do+some+work+on+second+row+..
++++second+=+second_row(ar)
++++work(second)

++++#+..+much+later+..
++++print(repr(ar))

if+__name__=="__main__":
++++main()|code-block|syntax|javascript|129220|它将打印|129221|array([[1,+0],
+++++++[0,+0]])|129222|这种行为总是让我感到惊讶。正在发生的事情是，df与ar共享内存，因此当work中的一些df内容发生更改时，该更改也会影响ar。然而，在某些情况下，出于内存效率的原因(无副本)，这可能正是您想要的。这段代码中真正的问题是，函数second_row返回的是第一行，而不是第二行；祝您在调试时好运。|offset|length|style|CODE|129223|请考虑用Rust编写的类似程序：|129224|#[derive(Debug)]
struct+Array<'a,+'b>(&'a+mut+[i32],+&'b+mut+[i32]);

impl<'a,+'b>+Array<'a,+'b>+{
++++fn+second_row(&mut+self)+->+&mut+&'b+mut+[i32]+{
++++++++&mut+self.0
++++}
}

fn+work(second:+&mut+[i32])+{
++++second[0]+=+1;
}

fn+main()+{
++++//+..+load+data+..
++++let+ar1+=+&mut+[0,+0][..];
++++let+ar2+=+&mut+[0,+0][..];
++++let+mut+ar+=+Array(ar1,+ar2);

++++//+..+do+some+work+on+second+row+..
++++{
++++++++let+second+=+ar.second_row();
++++++++work(second);
++++}

++++//+..+much+later+..
++++println!("{:?}",+ar);
}|129225|编译这段代码，你会得到|129226|error[E0308]:+mismatched+types
+-->+src/main.rs:6:13
++%7C
6+%7C+++++++++++++&mut+self.0
++%7C+++++++++++++%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E+lifetime+mismatch
++%7C
++=+note:+expected+type+`&mut+&'b+mut+[i32]`
+++++++++++++found+type+`&mut+&'a+mut+[i32]`
note:+the+lifetime+'b+as+defined+on+the+impl+at+4:5...
+-->+src/main.rs:4:5
++%7C
4+%7C+++++impl<'a,+'b>+Array<'a,+'b>+{
++%7C+++++%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E
note:+...does+not+necessarily+outlive+the+lifetime+'a+as+defined+on+the+impl+at+4:5
+-->+src/main.rs:4:5
++%7C
4+%7C+++++impl<'a,+'b>+Array<'a,+'b>+{
++%7C+++++%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E|129227|实际上你会得到两个错误，还有一个是'a和'b的角色互换了。查看second_row的注释，我们发现输出应该是&mut+&'b+mut+[i32]，也就是说，输出应该是对具有生存期'b+(Array的第二行的生存期)的引用的引用。但是，由于我们返回的是第一行(具有生存期'a)，编译器会抱怨生存期不匹配。在正确的地方。在正确的时间。调试是轻而易举的。|129228|entityMap^0|0|0|0|0|0|0|0|0|0|M|2|P|2|Z|4|17|2|1O|2|34|A|0|0|0|0|0|H|2|K|2|V|A|1I|I|2H|2|2L|5|3Q|2|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1D|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1E|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1G|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1H|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|1I|8|@]|9|@]|A|$]]|$1|R|3|S|5|M|7|1J|8|@]|9|@]|A|$N|O]]|$1|T|3|U|5|6|7|1K|8|@$V|1L|W|1M|X|Y]|$V|1N|W|1O|X|Y]|$V|1P|W|1Q|X|Y]|$V|1R|W|1S|X|Y]|$V|1T|W|1U|X|Y]|$V|1V|W|1W|X|Y]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1X|8|@]|9|@]|A|$]]|$1|11|3|12|5|M|7|1Y|8|@]|9|@]|A|$N|O]]|$1|13|3|14|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|15|3|16|5|M|7|20|8|@]|9|@]|A|$N|O]]|$1|17|3|18|5|6|7|21|8|@$V|22|W|23|X|Y]|$V|24|W|25|X|Y]|$V|26|W|27|X|Y]|$V|28|W|29|X|Y]|$V|2A|W|2B|X|Y]|$V|2C|W|2D|X|Y]|$V|2E|W|2F|X|Y]]|9|@]|A|$]]|$1|19|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]]|1A|$]]

As a newcomer to Rust, my understanding is that explicit lifetimes serve two purposes.

<ol>
<li>Putting an explicit lifetime annotation on a function restricts the type of code that may appear inside that function. Explicit lifetimes allow the compiler to ensure that your program is doing what you intended.</li>
<li>If you (the compiler) want(s) to check if a piece of code is valid, you (the compiler) will not have to iteratively look inside every function called. It suffices to have a look at the annotations of functions that are directly called by that piece of code. This makes your program much easier to reason about for you (the compiler), and makes compile times managable.</li>
</ol>

On point 1., Consider the following program written in Python:

<pre class="lang-py prettyprint-override"><code>import pandas as pd
import numpy as np

def second_row(ar):
 return ar[0]

def work(second):
 df = pd.DataFrame(data=second)
 df.loc[0, 0] = 1

def main():
 # .. load data ..
 ar = np.array([[0, 0], [0, 0]])

 # .. do some work on second row ..
 second = second_row(ar)
 work(second)

 # .. much later ..
 print(repr(ar))

if __name__=="__main__":
 main()
</code></pre>

which will print

<pre class="lang-none prettyprint-override"><code>array([[1, 0],
 [0, 0]])
</code></pre>

This type of behaviour always surprises me. What is happening is that <code>df</code> is sharing memory with <code>ar</code>, so when some of the content of <code>df</code> changes in <code>work</code>, that change infects <code>ar</code> as well. However, in some cases this may be exactly what you want, for memory efficiency reasons (no copy). The real problem in this code is that the function <code>second_row</code> is returning the first row instead of the second; good luck debugging that.

Consider instead a similar program written in Rust:

<pre><code>#[derive(Debug)]
struct Array&lt;'a, 'b&gt;(&amp;'a mut [i32], &amp;'b mut [i32]);

impl&lt;'a, 'b&gt; Array&lt;'a, 'b&gt; {
 fn second_row(&amp;mut self) -&gt; &amp;mut &amp;'b mut [i32] {
 &amp;mut self.0
 }
}

fn work(second: &amp;mut [i32]) {
 second[0] = 1;
}

fn main() {
 // .. load data ..
 let ar1 = &amp;mut [0, 0][..];
 let ar2 = &amp;mut [0, 0][..];
 let mut ar = Array(ar1, ar2);

 // .. do some work on second row ..
 {
 let second = ar.second_row();
 work(second);
 }

 // .. much later ..
 println!("{:?}", ar);
}
</code></pre>

Compiling this, you get

<pre class="lang-none prettyprint-override"><code>error[E0308]: mismatched types
 --&gt; src/main.rs:6:13
 |
6 | &amp;mut self.0
 | ^^^^^^^^^^^ lifetime mismatch
 |
 = note: expected type `&amp;mut &amp;'b mut [i32]`
 found type `&amp;mut &amp;'a mut [i32]`
note: the lifetime 'b as defined on the impl at 4:5...
 --&gt; src/main.rs:4:5
 |
4 | impl&lt;'a, 'b&gt; Array&lt;'a, 'b&gt; {
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...does not necessarily outlive the lifetime 'a as defined on the impl at 4:5
 --&gt; src/main.rs:4:5
 |
4 | impl&lt;'a, 'b&gt; Array&lt;'a, 'b&gt; {
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
</code></pre>

In fact you get two errors, there is also one with the roles of <code>'a</code> and <code>'b</code> interchanged. Looking at the annotation of <code>second_row</code>, we find that the output should be <code>&amp;mut &amp;'b mut [i32]</code>, i.e., the output is supposed to be a reference to a reference with lifetime <code>'b</code> (the lifetime of the second row of <code>Array</code>). However, because we are returning the first row (which has lifetime <code>'a</code>), the compiler complains about lifetime mismatch. At the right place. At the right time. Debugging is a breeze.

blocks|key|2905400|text|我认为生命周期注释是关于给定ref的约定，只有当它在源作用域中保持有效时，它才在接收作用域中有效。在同一生命周期中声明更多的引用相当于合并了作用域，这意味着所有的源引用都必须满足这个约定。这样的注解允许编译器检查契约的履行情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2905401|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think of a lifetime annotation as a contract about a given ref been valid in the receiving scope only while it remains valid in the source scope. Declaring more references in the same lifetime kind of merges the scopes, meaning that all the source refs have to satisfy this contract.
Such annotation allow the compiler to check for the fulfillment of the contract.

I was reading the <a href="https://doc.rust-lang.org/book/first-edition/lifetimes.html" rel="noreferrer">lifetimes chapter</a> of the Rust book, and I came across this example for a named/explicit lifetime:

<pre><code>struct Foo&lt;'a&gt; {
 x: &amp;'a i32,
}

fn main() {
 let x; // -+ x goes into scope
 // |
 { // |
 let y = &amp;5; // ---+ y goes into scope
 let f = Foo { x: y }; // ---+ f goes into scope
 x = &amp;f.x; // | | error here
 } // ---+ f and y go out of scope
 // |
 println!("{}", x); // |
} // -+ x goes out of scope
</code></pre>

It's quite clear to me that the error being prevented by the compiler is the use-after-free of the reference assigned to <code>x</code>: after the inner scope is done, <code>f</code> and therefore <code>&amp;f.x</code> become invalid, and should not have been assigned to <code>x</code>.

My issue is that the problem could have easily been analyzed away without using the explicit <code>'a</code> lifetime, for instance by inferring an illegal assignment of a reference to a wider scope (<code>x = &amp;f.x;</code>).

In which cases are explicit lifetimes actually needed to prevent use-after-free (or some other class?) errors?

Why are explicit lifetimes needed in Rust?

防火墙

编译器

Python

我正在读“生锈的”这本书，我偶然发现了这个例子，关于一个命名的/显式的生命周期：struct Foo<'a> { x: &'a i32,}fn main() { let x; // -+ x goes into scope ...

问为什么在Rust中需要显式生命周期？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在Rust中需要显式生命周期？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在Rust中需要显式生命周期？
EN