rust - 生命周期注释，或 &str vs String

Question

我有一个小库，可以导出带有生命周期注释的结构。现在我尝试从另一个程序使用它，但似乎我现在也需要在那里使用生命周期注释。基本上我是这样做的:

// in my lib
struct Foo<'a> {
    baz: &'a str
}

// another program
struct Bar {
    foo: Foo
}

其中说Bar必须为 Foo 定义生命周期:

<anon>:6:10: 6:13 error: wrong number of lifetime parameters: expected 1, found 0 [E0107]
<anon>:6     foo: Foo
                  ^~~

这很容易修复:

struct Bar<'a> {
    foo: Foo<'a>
}

但这意味着我现在还必须为任何使用 Bar 的东西定义生命周期等等，对吗？如果这是真的，除了使用不需要显式生命周期的类型之外，还有什么办法可以解决这个问题吗？或者使用像 String 这样的自有类型会更好吗？无论如何？

一些背景知识，我使用了 &str因为我不得不调用一个需要作为参数的函数。虽然转换它们没问题，但它实际上是一个 Vec<(&str, &str)> ，所以我的想法是首先通过使用正确的类型来摆脱转换。我觉得那是个错误的决定，但我知道什么……:)

Answer 1

是的，目前没有办法解决显式生命周期的冒泡问题。考虑它的方式是Foo需要明确与哪个生命周期相关联，因为 baz field 依赖于它，例如，编译器知道如果你试图使 Foo 停止你。比数据活得久baz引用，或者这样您就可以拥有返回“与 baz 一样长寿”的引用的方法。如果您随后嵌入 Foo进入Bar , 现在 Bar需要明确的生命周期，因为 Foo取决于它。

如果Foo是“拥有”字符串，意思是如果 Foo应该能够独立于任何可能的生命周期(例如范围)，那么它确实应该是 String .从 String 转换切片的成本非常低，因为切片只是现有数据的一个 View 。

但是，如果您总是构建Foo基于绑定(bind)到范围的现有数据(例如，传递给包含 Foo 实例的函数的字符串切片等)和 Foo实例不需要超过现有数据的范围，那么如果您将其设为 String您必须将切片转换为 String (与相反的情况相比，这相对昂贵)只是在使用时将其转换回切片，在这种情况下，您应该将其保留为切片。您当然不应该仅仅为了避免必须键入显式生命周期而招致这种性能损失。

您会发现具有显式生命周期的类型非常普遍，所以虽然一开始它确实令人担忧，但您会习惯的。