About <'aa> lifetime

help
1

Hi, when do i need a <'aa> lifetime ?

struct S2<'aa> {
    a: &'aa str,
    b: int
}
2

You need a string slice with a lifetime when you want S2 to not own the data in the string, instead having some other struct own the string with S2 just being a temporary borrow of that other value.

3

difference with:

struct S2<'a> {
    a: &'a str,
    b: int
}

?

4

The letters in the lifetime is just a name. You can call it whatever you want.

2 Likes
5

And, it is often helpful to NOT use lifetime names like a, aa, b, etc. Instead, use meaningful names if you can think of them. For example, in the above, instead of:

struct S2<'aa> {
    a: &'aa str,
    b: int
}

Do:

struct S2<'lifeofusername> {
    username: &'lifeofusername str,
    userid: int
}

Now, some will object to this as being verbose, but, I just don't buy it. In the above, it is now clear that the lifetime of S2 is tied to the lifetime of username. The reads, "S2 must have a lifetime no greater than the lifetime lifeofusername which is the lifetime of the borrow/reference member username.

[NOTE: Edited here to add the "NO" I accidentally left out].

EDIT 2: Now, if you read " ' (single-quote)" as "lifetime of", then the above can just be:

struct S2<'username> {
    username: &'username str,
    userid: int
}

which nicely reads as, "struct S2 must have a lifetime no longer than the lifetime of username"

14 Likes
6

Hi gbutler, i have one technico-philosophic question about time to die for lifetimes :wink:

struct S2 must have a lifetime no longer than the lifetime of username

does the GarbageCollector kill as fast as possible the struct, or does it prevent precoce death of the borrowed &str ?
Does exist a kind or Vector of the Death ?

7

Rust does not use a Garbage Collector. Rust uses ownership/lifetime tracking at compile time to know when something is no longer in use. At the point where the compiler determines the thing is no longer in use, it inserts the necessary "Drop" automatically (usually at the end of the block, but, not necessarily so).

What the "lifetimes" I mentioned above denote is that because S2 contains a reference (i.e. borrow) of a "str" (String slice), then, S2 cannot outlive that borrowed str (here named username). Because the struct is so defined, when you create an instance of that struct, the str that username points to must be guaranteed to exist as long as the instance of S2 exists. So, the instance of S2 cannot outlive the borrow/reference of/to the username : &str. The compiler ensures that your usages uphold this, and if they don't, it is a compile error (rather than a runtime error or undefined behavior).

1 Like
8

I have noticed this naming problem in Rust and a couple of other languages. It usually happens to generic arguments, e.g. FooBar<T, U, V>. It's funny how people can pay close attention to properly naming types, variables and function parameters, but at the same time ignore other symbols. I am guilty of that too.

9

thank you everybody

10

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.