Confused about ownership in situations involving lines and map

Question

fn problem() -> Vec<&'static str> {
    let my_string = String::from("First Line\nSecond Line");
    my_string.lines().collect()
}

This fails with the compilation error:

  |
7 |     my_string.lines().collect()
  |     ---------^^^^^^^^^^^^^^^^^^
  |     |
  |     returns a value referencing data owned by the current function
  |     `my_string` is borrowed here

I understand what this error means - it's to stop you returning a reference to a value which has gone out of scope. Having looked at the type signatures of the functions involved, it appears that the problem is with the lines method, which borrows the string it's called on. But why does this matter? I'm iterating over the lines of the string in order to get a vector of the parts, and what I'm returning is this "new" vector, not anything that would (illegally) directly reference my_string.

(I'm aware I could fix this particular example very easily by just using the string literal rather than converting to an "owned" string with String::from. This is a toy example to reproduce the problem - in my "real" code the string variable is read from a file, so I obviously can't use a literal.)

What's even more mysterious to me is that the following variation on the function, which to me ought to suffer from the same problem, works fine:

fn this_is_ok() -> Vec<i32> {
    let my_string = String::from("1\n2\n3\n4");
    my_string.lines().map(|n| n.parse().unwrap()).collect()
}

The reason can't be map doing some magic, because this also fails:

fn also_fails() -> Vec<&'static str> {
    let my_string = String::from("First Line\nSecond Line");
    my_string.lines().map(|s| s).collect()
}

I've been playing about for quite a while, trying various different functions inside the map - and some pass and some fail, and I've honestly no idea what the difference is. And all this is making me realise that I have very little handle on how Rust's ownership/borrowing rules work in non-trivial cases, even though I thought I at least understood the basics. So if someone could give me a relatively clear and comprehensive guide to what is going on in all these examples, and how it might be possible to fix those which fail, in some straightforward way, I would be extremely grateful!

Answer 1

The key is in the type of the value yielded by lines: &str. In order to avoid unnecessary clones, lines actually returns references to slices of the string it's called on, and when you collect it to a Vec, that Vec's elements are simply references to slices of your string. So, of course when your function exits and the string is dropped, the references inside the Vec will be dropped and invalid. Remember, &str is a borrowed string, and String is an owned string.

The parsing works because you take those &strs then you read them into an i32, so the data is transferred to a new value and you no longer need a reference to the original string.

To fix your problem, simply use str::to_owned to convert each element into a String:

fn problem() -> Vec<String> {
    let my_string = String::from("First Line\nSecond Line");
    my_string.lines().map(|v| v.to_owned()).collect()
}

It should be noted that to_string also works, and that to_owned is actually part of the ToOwned trait, so it is useful for other borrowed types as well.

For references to sized values (str is unsized so this doesn't apply), such as an Iterator<Item = &i32>, you can simply use Iterator::cloned to clone every element so they are no longer references.

An alternative solution would be to take the String as an argument so it, and therefore references to it, can live past the scope of the function:

fn problem(my_string: &str) -> Vec<&str> {
    my_string.lines().collect()
}