为什么不能在结构定义中忽略生命周期? [英] Why can the lifetimes not be elided in a struct definition?

问题描述

struct Point {
    x: u32,
    y: u32,
}

struct Line<'a> {
    start: &'a Point,
    end: &'a Point,
}

在这里，start和end字段的唯一可能的选择是使生存期与包含它们的Line变量相同或更长.我什至无法想象如何使用生命周期说明符来说明字段的寿命较短.

Here, the only possible option for the start and end fields is to have a lifetime the same or longer than the Line variable that contains them. I can't even imagine how one will go about using a lifetime specifier to say that the fields have a shorter lifespan.

为什么我必须在这里明确指定生存期?在这种情况下不可能进行省略，如果可以，为什么不可以?

Why do I have to explicitly specify a lifetime here? Is elision not possible in this situation and if so why not?

推荐答案

定义结构时，您并未在结构的寿命和字段的寿命之间建立联系.正如您所指出的那样，字段中的引用具有的寿命比该结构的寿命长.

When you define a struct, you aren't making a relation between the lifetime of the struct and the lifetime of the fields. As you point out, the references in the fields have to live longer than the struct.

相反，您正在做的是提供一个通用寿命"，该寿命将在创建结构时专门化.这类似于具有类型参数的结构:

Instead, what you are doing is providing a "generic lifetime" that will be specialized when you create the struct. This is similar to having a struct with a type parameter:

struct Foo<T>
    foo: T,
}

构造该结构时，编译器将插入适当的生存期(或类型)，然后它检查所有内容是否仍然有效.

When you construct the struct, appropriate lifetimes (or types) will be inserted by the compiler, and then it checks that everything still works out.

另一件事是，您可以相对于彼此指定 的生存期:

The other thing is that you can specify the lifetimes with respect to each other:

struct Line<'a, 'b: 'a> {
    start: &'a Point,
    end: &'b Point,
}

这表示start和end可以具有不同的生存期，只要end的生存期生存期的生存期 start.start. /p>

This says that start and end can have different lifetimes, so long as the lifetime of end outlives the lifetime of start.

为什么编译器不对结构进行生命周期清除?似乎在 Rust的精神中这样做

(重点是我的)

我实际上认为Rust倾向于 explicitness ，特别是在定义顶级项(例如函数，结构)时.

I actually believe that Rust tends towards explicitness, especially when it comes to defining top-level items (like functions, structs).

函数生命周期省略规则的范围很小，并且是

The rules for lifetime elision for functions have a pretty small scope and were empirically found in RFC 141 to have a high success rate (87%). This was a very good ergonomic return on investment.

也许在某个时候，类似的省略会出现在结构上，但是还不是一个足够大的问题，还.如果您对此有强烈的感觉，那么我强烈建议您在用户论坛上寻求共识进入开发者论坛，然后最终制定RFC.

Perhaps at some point, similar elision will occur for structs, but it hasn't been a big enough problem yet. If you feel strongly about this, then I'd highly recommend asking for consensus on the user forum, progressing to the developer forum, then ultimately making an RFC.

RFC 2093 添加了一个少量的推断.在实现之前，您必须表达一个泛型作为引用需要比该引用更久:

RFC 2093 adds a small amount of inference. Before it is implemented, you have to express that a generic type as a reference needs to outlive the reference:

struct Foo<'a, T: 'a> {
    start: &'a T,
}

在任何情况下，您都不想要此绑定，因此在实施RFC之后，您可以说:

There's no case in which you wouldn't want this bound, so after the RFC is implemented, you can just say:

struct Foo<'a, T> {
    start: &'a T,
}

这篇关于为什么不能在结构定义中忽略生命周期?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！