Rust 生命周期省略的第三条规则是否涵盖了结构实现的所有情况？

终身省略的第三条规则是

如果有多个输入生存期参数，但其中一个是

&self

或

&mut self

，因为这是一种方法，则

self

的生存期将分配给所有输出生存期参数。这使得写作方法变得更好

下面是描述此函数发生了什么的示例

fn announce_and_return_part(&self, announcement: &str) -> &str

有两个输入生存期，因此Rust应用第一个生存期省略规则，并为

&self

和

announcement

提供各自的生存期。然后，因为其中一个参数是

&self

，所以返回类型获取

&self

的生存期，并且所有的生存期都已计算在内

我们可以证明，所有的生存期都没有考虑在内，因为

公告

的生存期可能与

&self

的不同：

struct ImportantExcerpt<'a> {
    part: &'a str,
}

impl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part(&self, announcement: &str) -> &str {
        println!("Attention please: {}", announcement);
        announcement
    }
}

fn main() {
    let i = ImportantExcerpt { part: "IAOJSDI" };
    let test_string_lifetime;

    {
        let a = String::from("xyz");
        test_string_lifetime = i.announce_and_return_part(a.as_str());
    }
    println!("{:?}", test_string_lifetime);   
}

struct importantextercept{
fn宣布和返回部分（&self，宣布：&str）->&str{
println！（“请注意：{}”，公告）；
公告
}
}
fn main（）{
设i=ImportantExcerpt{part:“IAOJSDI”}；
让测试_字符串_寿命；
{
设a=String:：from（“xyz”）；
test_string_life=i.annound_和_return_部分（a.as_str（））；
}
println！（“{：？}”，测试字符串寿命）；
}

公告

的生存期没有

&self

长，因此将输出生存期与

&self

关联是不正确的，输出生存期不应该与较长的输入相关联吗

为什么生命周期省略的第三条规则是分配输出生命周期的有效方法？

不，省略规则不能捕获生命周期的所有可能情况。如果有，那么就不会有任何省略规则，它们将是唯一的规则，我们不需要任何语法来指定显式的生存期

引用您链接到的文档，重点是我的：

在Rust的参考分析中编程的模式称为 终身省略规则。这些不是程序员要遵守的规则 跟随；这些规则是编译器将要处理的一组特殊情况 考虑一下，如果你的代码适合这些情况，你就不需要写了。 生命周期是显式的

省略规则不提供完整的推断：如果 决定性地应用规则，但仍有模糊性 引用的生命周期是多少，它不会猜测生命周期是多少 其余的引用中的一个应为。在这种情况下，编译器将 提供一个可以通过添加生存期来解决的错误 与您的意图相对应的注释，用于说明引用的方式 相互联系

---

公告

的生存期没有

&self

长，因此将输出生存期与

&self

关联是不正确的

为什么生命周期省略的第三条规则是分配输出生命周期的有效方法

“correct”这个词在这里可能不合适。省略规则所做的是一种有效的方法，它恰好不是您想要的

输出生命周期不应该与较长的输入相关联吗

是的，对于这个例子来说这是可以接受的，这不是最常见的情况，所以这不是省略规则的目的

另见：

---

但是在文档中它说

，然后，因为其中一个参数是&self，返回类型得到&self的生存期，并且所有的生存期都已计算。

，但是似乎所有的生存期都没有计算，编译器如何知道分配

&self

生存期是有效的？@Jal yes，所有需要生存期的参数/返回类型都已分配了生存期，但这并不意味着编译器分配的生存期是最精确的，或者是您需要的。也许问题只是集中在短语“accounted accounted”的语义上？啊，我明白了，编译器只是将生存期分配给最一般的情况，这可能是一种不正确的情况。@Jal:我想补充一点，编译器不必看函数的实现。生存期省略规则只关注函数签名。如果它匹配某个模式，则会自动分配生存时间

fn（&self，&str）->&str

总是

fn&'a str

的缩写，无论您如何实现该功能。在您的情况下，这种匹配模式不是您想要的，这就是为什么您必须具体说明生命周期。

它不会猜测剩余引用的生命周期应该是多少。

。显然，这里的编译器似乎在猜测。当我读到这本书的那一部分时——甚至是那些精确的引用——我也想到了同样的事情：编译器只在普通情况下使用省略规则，在这种情况下，设置显式生存期的方法只有一种。显然不是。这本书可以用一些更好的措辞来澄清这一点。当我读到这本书时，我和你的想法完全一样。我想与下面的响应一起需要知道的重要一点是，您发布的代码无法编译，抱怨

announcement

参数与函数原型中的返回类型之间存在

生存期不匹配

，明确地注意到您正在从

announcement

返回数据。谢谢你发布这篇文章。顺便说一下，对于未来的谷歌用户：如果你在

announcement

中添加了一个显式（和匹配的）生存期，并在原型中添加了返回类型，那么函数会编译，但rust（正确地）会在

main（）

中抱怨生存期不够长。