ch10-03 Explanation of lifetime bounds is confusing/incorrect

[d0sboots]

• I have checked the latest main branch to see if this has already been fixed
• I have searched existing issues and pull requests for duplicates

This overlaps a bit with #1710, but IMO it's a separate issue.

URL to the section(s) of the book with this problem:
https://github.com/rust-lang/book/blob/main/src/ch10-03-lifetime-syntax.md

Description of the problem:

The function signature now tells Rust that for some lifetime 'a, the function takes two parameters, both of which are string slices that live at least as long as lifetime 'a. The function signature also tells Rust that the string slice returned from the function will live at least as long as lifetime 'a.

This isn't true as I understand it. For instance, suppose the lifetime 'a only lasts until immediately after program start. Then (vacuously), both of the function's parameters will live at least as long as that lifetime (they definitely live longer), and the slice returned from the function will also live at least as long as 'a. By the description given, this should be a valid lifetime for the parameter 'a, but it's clearly not - the semantics given might be necessary, but are nowhere near sufficient.

Suggested fix:
I'm a Rust newbie, so I have no idea what the correct lifetime is. I tried finding the wording in the spec, to no avail.

[carols10cents]

For instance, suppose the lifetime 'a only lasts until immediately after program start.

Can you construct an example that illustrates this?

[d0sboots]

The example was listed in the book itself:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

Obviously the lifetime annotations work correctly in practice. But given the description in the book, they don't: 'a could last only until program start. This is because of the 2nd sentence:

The function signature also tells Rust that the string slice returned from the function will live at least as long as lifetime 'a.

If 'a only lasts until program start, this condition is satisfied, despite it not guaranteeing anything useful about the lifetimes of x, y, or the return value. I think maybe this sentence was supposed to be: "The function signature also tells Rust that lifetime 'a will live at least as long as the string slice returned from the function."

[carols10cents]

No, can you give me an example of a main function where the lifetime of the value only lasts until program start? That is, I don't understand what you mean by "If 'a only lasts until program start", could you please construct that scenario in concrete code for me?

[d0sboots]

I feel like we're talking past each other here.

I can't construct that scenario for you in code, because such a scenario can't exist. That's because there's nothing wrong with lifetimes in terms of how they actually work, so any code example would work just fine (because the only way you could interpret it would be according to the actual rules that Rust uses.)

What this bug is about is about the explanation of lifetimes, as given in the book. In other words, if we take the book's explanation as canonical for how lifetimes work, where does that lead, logically? And I'm saying that the explanation is flawed.

The example I gave has "the lifetime of 'a only lasting until program start." I don't know what that would mean, concretely. That's because the book hasn't given any formal semantics to the meaning of the lifetime parameters; up until this point it has just given rules determining how the length of them relate to the lifetime of actual variables and return values. All I know is that the scenario I laid out ("the lifetime of 'a only lasting until program start") is logically consistent with the book's explanation, despite being nonsensical in terms of practical meaning.

[d0sboots]

If you're still hung up on the "only until program start" bit, here's another way of looking at it:

'a could also have a lifetime that ends immediately before the function is called. That would also be logically consistent with the explanation, and is also nonsense in terms of actually making sense for lifetimes.

[carols10cents]

'a could also have a lifetime that ends immediately before the function is called. That would also be logically consistent with the explanation, and is also nonsense in terms of actually making sense for lifetimes.

It can't, though, because if it ends then you don't have a value to pass to the function. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b6cb1ecf171f98d721d8fcbfccbe98b6

fn main() {
    let s1 = String::from("hi");
    let s2 = String::from("bye");
    drop(s1); // This ends the lifetime of s1
    drop(s2); // This ends the lifetime of s2
    let s3 = longest(&s1, &s2); // You can try to make 'a be a lifetime that has ended, but it won't compile
}

results in

error[[E0382]](https://doc.rust-lang.org/stable/error-index.html#E0382): borrow of moved value: `s1`
 --> src/main.rs:6:22
  |
2 |     let s1 = String::from("hi");
  |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
3 |     let s2 = String::from("bye");
4 |     drop(s1);
  |          -- value moved here
5 |     drop(s2);
6 |     let s3 = longest(&s1, &s2);
  |                      ^^^ value borrowed here after move

error[[E0382]](https://doc.rust-lang.org/stable/error-index.html#E0382): borrow of moved value: `s2`
 --> src/main.rs:6:27
  |
3 |     let s2 = String::from("bye");
  |         -- move occurs because `s2` has type `String`, which does not implement the `Copy` trait
4 |     drop(s1);
5 |     drop(s2);
  |          -- value moved here
6 |     let s3 = longest(&s1, &s2);
  |                           ^^^ value borrowed here after move

I don't understand why you're trying to understand the formal semantics of lifetimes by using situations that can't exist?

[carols10cents]

That's because the book hasn't given any formal semantics to the meaning of the lifetime parameters; up until this point it has just given rules determining how the length of them relate to the lifetime of actual variables and return values.

The formal semantics of the meaning of the lifetime parameters is that they describe the relationship of the input parameters' lifetimes to the output's lifetime, as explained here:

Lifetime annotations don’t change how long any of the references live. Rather,
they describe the relationships of the lifetimes of multiple references to each
other without affecting the lifetimes. Just as functions can accept any type
when the signature specifies a generic type parameter, functions can accept
references with any lifetime by specifying a generic lifetime parameter.

I don't understand what you're looking for, exactly, and why this paragraph isn't it.

[d0sboots]

'a could also have a lifetime that ends immediately before the function is called. That would also be logically consistent with the explanation, and is also nonsense in terms of actually making sense for lifetimes.

It can't, though, because if it ends then you don't have a value to pass to the function. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b6cb1ecf171f98d721d8fcbfccbe98b6

fn main() {
    let s1 = String::from("hi");
    let s2 = String::from("bye");
    drop(s1); // This ends the lifetime of s1
    drop(s2); // This ends the lifetime of s2
    let s3 = longest(&s1, &s2); // You can try to make 'a be a lifetime that has ended, but it won't compile
}

This example doesn't show anything (directly) about the lifetime parameter 'a. It shows that the lifetimes of s1 and s2 can't end before the function, but the lifetimes of the input arguments are a different thing than 'a. There is no way to prove (or disprove) a particular value for a lifetime parameter with code, because AFAIK Rust never emits diagnostics that mention the value of lifetime parameters, only the lifetimes of concrete references.

The formal semantics of the meaning of the lifetime parameters is that they describe the relationship of the input parameters' lifetimes to the output's lifetime, as explained here:

Lifetime annotations don’t change how long any of the references live. Rather,
they describe the relationships of the lifetimes of multiple references to each
other without affecting the lifetimes. Just as functions can accept any type
when the signature specifies a generic type parameter, functions can accept
references with any lifetime by specifying a generic lifetime parameter.

This gets to the heart of the issue. Lifetime parameters don't have any intrinsic meaning on their own; the only meaning they have is in relating the lifetimes of concrete references. So, it is perfectly sensible to talk about hypotheticals where "'a has a lifetime that ends immediately after the program starts," or "'a has a lifetime that ends before the function is called," because that's not a claim that any specific reference has that property.

In the context of how Rust actually works, these hypothetical lifetimes would be impossible for 'a, because they would imply lifetimes for the concrete references that are also impossible. But I'm not talking about how Rust actually works, but the language in the book. If you go by the semantics as described in the book, these lifetimes are possible.

[carols10cents]

Let's try a different direction, just with generic type parameters for a moment. Given this example:

fn something<T: Copy>(input: T) -> T {
    // ...
}

This says the function accepts some type T as the parameter input and returns that same type T, and that whatever the type T ends up being, it must implement the Copy trait.

When you say:

So, it is perfectly sensible to talk about hypotheticals where "'a has a lifetime that ends immediately after the program starts," or "'a has a lifetime that ends before the function is called,"

It's akin to saying "let's talk about a hypothetical where the something function returns a String" (a type that doesn't implement the Copy trait), and I'm saying there's no reason to talk about that because it's impossible, given the constraints that the something function specifies.

Lifetime parameters get filled in with concrete lifetimes when the functions are used, and those lifetimes must be valid ones. I wonder if maybe that's the problem? That the book doesn't specifically say in this spot that all references must be valid? (It's said elsewhere).

[carols10cents]

but the lifetimes of the input arguments are a different thing than 'a

What makes you say this, exactly? The lifetime parameter 'a is absolutely describing the lifetimes of the input arguments.

Making an analogy with generics again, it sounds like here you're saying because, say, i32 also implements the PartialEq trait, then the traits implemented by the input argument if you pass an i32 value to the something function is a different thing than the generic type parameter T that implements the Copy trait. What I'm trying to say is that T: Copy is still describing the i32 argument even if they're "different".

[carols10cents]

because AFAIK Rust never emits diagnostics that mention the value of lifetime parameters, only the lifetimes of concrete references.

I have an example of diagnostics that mention the value of lifetime parameters, here:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
    y
}

results in

error[[E0623]](https://doc.rust-lang.org/stable/error-index.html#E0623): lifetime mismatch
 --> src/lib.rs:2:5
  |
1 | fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
  |                                   -------     -------
  |                                   |
  |                                   this parameter and the return type are declared with different lifetimes...
2 |     y
  |     ^ ...but data from `y` is returned here

[d0sboots]

I agree, let's try a different direction. What does this sentence (from the book) mean, to you?

The function signature also tells Rust that the string slice returned from the function will live at least as long as lifetime 'a.

I think we might be closing in on the confusion with your example of generic types, though. You seem to think generic types and lifetime parameters work the same way. I don't. I suspect you're correct (since I'm new to Rust), so let me try to explain how I see the difference, which comes from the explanation in the book.

fn something<T: Copy>(input: T) -> T {
    // ...
}

As you said, in this case the type parameter T and the type of input must be the same. Also, T (and thus input) is bounded by needing to implement Copy.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    // ...
}

The function signature now tells Rust that for some lifetime 'a, the function takes two parameters, both of which are string slices that live at least as long as lifetime 'a. The function signature also tells Rust that the string slice returned from the function will live at least as long as lifetime 'a.

There is a crucial difference here: x and y do not have lifetimes that are the same as 'a, but rather have lifetimes that are at least as long as lifetime 'a. Or at least, that is what the words from the book seem to literally say.

Similarly, right now the book says the return type will live at least as long as lifetime 'a. It's not the same as 'a.

Does this clear things up?

[d0sboots]

I have an example of diagnostics that mention the value of lifetime parameters, here:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
    y
}

results in

error[[E0623]](https://doc.rust-lang.org/stable/error-index.html#E0623): lifetime mismatch
 --> src/lib.rs:2:5
  |
1 | fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
  |                                   -------     -------
  |                                   |
  |                                   this parameter and the return type are declared with different lifetimes...
2 |     y
  |     ^ ...but data from `y` is returned here

This still doesn't mention the value of lifetime parameters. It highlights that the lifetime parameters are different, but it doesn't say what their values are (i.e. what the actual lifetimes of those parameters are). This might seem like a minor quibble, but if I'm right about how lifetime parameters work it's essentially impossible for diagnostics to emit a concrete value for a lifetime parameter, because they don't actually have one. (I.e. they're only used to bound the lifetimes of concrete references, which do have concrete lifetimes.)