我在网上找到了很多有关 Rust 生命周期的信息，包括有关静态生命周期的信息。对我来说，在某些情况下，你必须保证引用比所有东西都更长寿，这是有道理的。
例如，我有一个要传递给线程的引用，编译器要求将该引用标记为静态。在这种情况下，这似乎是有意义的，因为编译器无法知道线程的生存时间，因此需要确保传递的引用比线程的生存时间长。 （我认为这是正确的？）
我不知道这是从哪里来的，但我总是担心用静态生命周期标记某些东西是值得怀疑的，并尽可能避免。
所以我想知道这是否正确。我应该对用静态生命周期标记事物持批评态度吗？是否存在编译器想要需要一种策略，但替代策略实际上可能更优化的情况？
我可以通过哪些具体方法来推断静态生命周期的应用，并可能确定它何时不合适？
正如您可能已经猜到的那样，对此没有明确的技术答案。
作为 Rust 的新手，'static引用似乎违背了借用系统的全部目的，并且有一个想法可以避免它们。一旦你变得更有经验，这种想法就会消失。
首先，'static看起来并不坏，因为所有没有其他生命周期与之相关的事物都是'static, e.g. String::new()。请注意'static does not意味着所讨论的价值确实永远存在。这只是意味着价值可以制作永远活下去。在您的线程示例中，线程无法对其自己的生命周期做出任何承诺，因此它需要能够to make所有传递给它的东西都永远存在。任何拥有的价值，不包括短于'static (like vec![1,2,3]) 可以制作永远活下去（只是不摧毁它们），因此'static.
Second, &'static- 静态参考 - 无论如何不会经常出现。如果是这样，您通常会知道原因。你不会看到很多fn foo(bar: &'static Bar)因为它根本没有那么多用例，而不是因为它被积极避免。
有些情况'static确实以令人惊讶的方式出现。意料之外：
- A
Box<dyn Trait> is 隐含地 https://rust-lang.github.io/rfcs/1156-adjust-default-object-bounds.html a Box<dyn Trait + 'static>。这是因为当里面的值的类型Box被擦除，它可能有与之相关的生命周期；并且所有（不同的）类型都必须有效Box生活。因此，所有类型都需要在其生命周期中共享一个共同点，而 Rust 被定义为选择'static。这种选择通常是可以的，但可能会导致令人惊讶的“需要'静态”错误。您可以将其明确概括为Box<dyn Trait + 'a>
- 如果你有定制
impl Drop根据您的类型，Drop-checkermay https://doc.rust-lang.org/nomicon/dropck.html无法证明析构函数无法观察到已经被删除的值。为了防止Dropimpl 不访问对已删除值的引用，编译器要求整个类型仅具有'static里面有参考文献。这可以通过不安全的实现来克服，它会提升'static-要求。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
