Blog

Sandbox

The repo where I tested out these ideas is
here.

The conversation I had with ChatGPT about the topic is
here. I do a
lot of my personal study with ChatGPT, so the conversation is worth a peek as
the majority of this content is derived from my studies there.

Afterthoughts

As I was writing this article, I noticed generics are really important regarding
lifetimes. I have a pretty solid understanding of generics already, but I think
going back and doing a post about them would be good after this.

NOTE TO SELF: Did you write a post about generics in Rust?

It's About Time

I've been avoiding this topic for a bit because of all the concepts in Rust,
lifetimes are the one I am most likely to just rely on compile-time errors to
help me manage and correct.

In short, when I write lifetimes, I have no idea what I am doing.

The only thing I can remember is a quote from
Tristram Oaten on his YouTube
channel, No Boilerplate.

He said, "..lifetimes let us know when our data is."

So, let's checkout
The Book and
see what it has to say on lifetimes.

The Book on Lifetimes

Right off the bat, we read a lifetime is, "..a construct the compiler (or more
specifically, its borrow checker) uses to ensure all borrows are valid."

Despite not feeling confident about lifetimes, I am pretty familiar with the
borrow-checker. I used Rust pretty early on in my programming journey (which is
why I've revisted the language 3 times now). Because of this, I've actually
inherited some good coding practices regarding how I think about handling data
within a program.

The book also points out that it can be easy to confuse lifetimes and scopes.
This is because scopes and lifetimes are closely related.

The real thing I notice here is that it is just important to know when your data
is valid in your Rust programs.

I think a pattern I came across when I first started Rust is the idea that you
can pass a variable into a function, us it within, and then return it if you
need it back.

The Book has a page on how to explicitly annotate lifetimes using some_var<'a>

Let me see what ChatGPT has to say about the topic.

ChatGPT on Lifetimes

ChatGPT makes it clear lifetimes are used to ensure references are valid for the
shortest amount of time possible. They enable us to tell the compiler when a
reference is no longer accessible.

Here is an example where we try to make use of a &x when it is no longer
available:

1fn dangling_reference() {
2    let r;
3    {
4        let x = 5;
5        r = &x;
6    }
7    // println!("{}", r); 💥 Dangling reference!
8}

Why Does This Matter?

Lifetimes become a practical problem in your code when you start passing
references around.

Take the following function for example:

1fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
2    if s1.len() > s2.len() {
3        s1
4    } else {
5        s2
6    }
7}

In this function, we use -> &'a str to state: "The returned reference will be
valid for the duration of lifetime 'a"

What is the duration of lifetime 'a you might ask?

The Shortest Lifetime

If a more than one reference is passed into a function, and the function returns
a new reference, the new reference will mirror the shortest lifetime of the
input references.

So, when we say state, (s1: &'a str, s2: &'a str) -> &'a str, what we are
really saying is:

"The lifetime of the return value will match s1 if s1 has the shortest lifetime,
or it will match s2 if s2 has the shortest lifetime."

This means when we are in a scenario where a reference is being passed from one
location to another, we need to be mindful of all the data points it comes into
contact with.

If we pipe a reference into a function, and that function outputs another
reference, our data is now "linked" from the compiler's perspective.

Every Reference Has a Lifetime

One thing to note is that all the references in a Rust program have a lifetime,
even if it is not explicitly annotated. Sometimes, Rust can even infer the
lifetime of a return value. These are called the
Elision Rules.

In short, elision rules allow us to forgo explicitly writing out our lifetime
annotations.

A good rule of thumb is if a function only has one reference passed into it,
then the annotation can be excluded because the return value will always match
that of the input reference.

I would take a peak at the Elision Rules though because I am not diving into all
the minute details here.

Common Scenarios

Here are a few common scenarios where lifetimes are found:

Structs

You may end up with a struct which has lifetime annotations like so:

1struct Car<'a> {
2    model: &'a str
3}

Functions

As already discussed, functions may have lifetime annotations:

1fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
2    if x.len() > y.len() {
3        x
4    } else {
5        y
6    }
7}

In Trait Bounds

We can also use lifetimes when using trait bounds:

1fn print_with_lifetime<'a, T>(item: &'a T)
2where
3    T: std::fmt::Display + 'a,
4{
5    println!("{}", item);
6}

Of all the things I've listed so far, ^ that one looks the most archaic to me. I
understand traits and their purpose, however, I need to brush up on actually
using traits in real world scenarios.

NOTE TO SELF: Did you do a deep dive on trait bounds in Rust?

Lifetimes as Timelines

ChatGPT suggested thinking of lifetimes in terms of timelines. When approach a
Rust program, we need to take special care to ensure we are being proactive
about how we are thinking about our references.

Remember, each reference has it's own timeline, and if you borrow a reference,
you need to make sure it lives long enough to be borrowed in the first place.

Conclusion

I think this first look at lifetimes is good, but I will definitely be back on
this topic. All in all, lifetimes are really all about making sure that
references are available for only the time they are needed and no more.

Lifetimes are Rusts way of avoiding common a pitfall like dangling references.

I have heard some complain about lifetimes "coloring" functions. Kind of similar
to how when you mark a function async in typescript, your whole codebase ends
up being marked with async.

I will be back on this one.