Lifetime in depth

1

This code compiles ad runs:

#[derive(Debug)]
struct A1<'a> {
      a01: &'a str,
      a02: i32,
}
fn main() {
      let v1 = vec!["aaa".to_string(), "bbb".to_string()];
      let a1 = A1 {
            a01 : &v1[0],
            a02 : 4,
    };
   println!("{}", a1.a01);

}

exactely what are we saying to the compiler with <'a>? Why compiler needs that we suggest this?
Thx

2

A lifetime parameter denotes a region or duration where a value is valid.

The compiler needs these validity annotations to prove memory safety of code. If the compiler didn't know which values are required to live at which place/time, it couldn't supply such proofs.

3

So, here we are saying to the compiler that how long references are valid is determined by the expression or block of code in which the struct is created? Correct?

4

Yes, basically, at a very basic level — and then there is a bunch of other, more nuanced rules (mainly around subtyping and variance).

Note that the concrete lifetimes can usually be inferred from the code locally (ie., within a function body). In the definition of a user-defined type, there's nothing to infer a concrete lifetime from. So you must communicate the fact that your type must be parameterized by a lifetime, and link any parameters of the contained lifetime-requiring types with those of your own type.

1 Like
5

The lifetime annotations are like breadcrumbs, tracing back all the way where the value is being borrowed from, to restrict usage of the struct to only that scope. If you borrow a local variable when making the struct instance, then the instance will be forever tied to the scope of this loan of this variable.

The annotations are like assertions checking what the code is doing. They do not influence compilation in any way. The compiler can't make anything live longer.

4 Likes
6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.