rust - 什么时候静态生命周期不合适？

Question

我在网上找到了很多关于 rust 生命周期的信息，包括关于静态生命周期的信息。对我来说，在某些情况下，您必须保证引用比一切都更有效。

例如，我有一个要传递给线程的引用，编译器要求将该引用标记为静态。在这种情况下，这似乎是有道理的，因为编译器不知道线程将存活多久，因此需要确保传递的引用比线程长。 (我认为这是正确的？)

我不知道这是从哪里来的，但我总是担心用静态生命周期标记某些东西是值得怀疑的，并尽可能避免。

所以我想知道这是否正确。我应该批评用静态生命周期标记事物吗？是否存在编译器需要一个，但替代策略实际上可能更优化的情况？

我可以通过哪些具体方法来推断静态生命周期的应用，并可能确定何时可能不合适？

Answer 1

您可能已经猜到了，对此没有明确的技术答案。

作为 Rust 的新手，'static引用似乎违背了借贷系统的全部目的，并且有一种避免它们的想法。一旦你变得更有经验，这个概念就会消失。

首先，'static看起来还不错，因为所有没有其他生命周期的东西都是'static ，例如String::new() .请注意 'static 不是否意味着所讨论的值(value)确实永远存在。这只是意味着值(value)可以使永远存在。在您的线程示例中，线程不能对自己的生命周期做出任何 promise ，因此它需要能够使传递给它的所有东西永远存在。任何不包括生命周期短于 'static 的拥有值(如 vec![1,2,3] )可以使永生(只需不破坏它们)，因此是 'static .

第二，&'static - 静态引用 - 无论如何不会经常出现。如果是这样，您通常会知道原因。你不会看到很多 fn foo(bar: &'static Bar)因为它根本没有那么多用例，而不是因为它被积极避免。

在某些情况下，'static确实以令人惊讶的方式出现。我的脑袋:

• 一个 Box<dyn Trait>是 implicitly一个 Box<dyn Trait + 'static> .这是因为当 Box 里面的值的类型被抹去，它可能有与之相关的生命周期；并且所有(不同的)类型必须在 Box 内有效。生活。因此，所有类型都需要在其生命周期内共享一个共同点，Rust 被定义为选择 'static .这种选择通常没问题，但可能会导致令人惊讶的“需要'静态”错误。您可以将其明确概括为 Box<dyn Trait + 'a>
• 如果您有自定义 impl Drop根据您的类型，Drop-checker may无法证明析构函数无法观察已删除的值。为了防止Drop impl 从访问对已删除的值的引用，编译器要求整个类型只有 'static里面的引用。这可以通过不安全的 impl 来克服，它会提升 'static -要求。