100

I just spent a week reading the Rust Book, and now I'm working on my first program, which returns the filepath to the system wallpaper:

pub fn get_wallpaper() -> &str {
    let output = Command::new("gsettings");
    // irrelevant code
    if let Ok(message) = String::from_utf8(output.stdout) {
        return message;
    } else {
        return "";
    }
}

I'm getting the error expected lifetime parameter on &str and I know Rust wants an input &str which will be returned as the output because any &str I create inside the function will be cleaned up immediately after the function ends.

I know I can sidestep the issue by returning a String instead of a &str, and many answers to similar questions have said as much. But I can also seemingly do this:

fn main() {
    println!("message: {}", hello_string(""));
}

fn hello_string(x: &str) -> &str {
    return "hello world";
}

to get a &str out of my function. Can someone explain to me why this is bad and why I should never do it? Or maybe it's not bad and okay in certain situations?

eiko
  • 5,110
  • 6
  • 17
  • 35
  • 3
    I don't really see how you can avoid this. You can try and make it cheaper, by preallocating buffers, but someone has to own this memory. You can't know the length of your string before reading it from the command's output. Allocating on the heap makes sense to me. – bluejekyll Mar 28 '17 at 20:33
  • @bluejekyll i've clarified my question to show one way you seemingly can get a &str out of a function simply by providing a dummy parameter to have a lifetime. – eiko Mar 28 '17 at 21:27

2 Answers2

120

You cannot return a &str if you've allocated the String in the function. There's further discussion about why, as well as the fact that it's not limited to strings. That makes your choice much easier: return the String.

Strings are heap-allocated and built to be mutable.

Strings are heap-allocated because they have an unknown length. Since that allocation is solely owned by the String, that's what grants the ability to mutate the string.

My function just returns a filepath for reference purposes, and I'd rather leave it up to the caller to decide if they need a heap-stored mutable string.

This isn't possible. Your function has performed an allocation. If you don't return the allocation to the caller, then the value must be deallocated to prevent memory leaks. If it was returned after deallocation, that would be an invalid reference, leading to memory safety violations.

But I can also seemingly do this:

fn hello_string(x: &str) -> &str {
    return "hello world";
}

to get a &str out of my function. Can someone explain to me why this is bad and why I should never do it? Or maybe it's not bad and okay in certain situations?

It's not bad, it just doesn't really allow you to do what you want in your original case. That "hello world" is a &'static str, a string slice that's been stored inside the code of the program itself. It has a fixed length and is known to live longer than main.

The signature fn hello_string(x: &str) -> &str can be expanded to fn hello_string<'a>(x: &'a str) -> &'a str. This indicates that the resulting string slice must have the same lifetime as the input string. A static string will outlive any lifetime, so that's valid to substitute.

This would be useful for a function where the result is based on the input string only:

fn long_string(x: &str) -> &str {
    if x.len() > 10 {
        "too long"
    } else {
        x
    }
}

However, in your case, the function owns the String. If you attempted to return a reference to a String, completely unrelated to the input string:

fn hello_string(x: &str) -> &str {
    &String::from("hello world")
}

You'll run into the common error message "borrowed value does not live long enough". That's because the borrowed value only lives until the end of method, not as long as the input string slice. You can't "trick" the compiler (or if you can, that's a major bug).

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
  • 2
    Aren't references just like a (C/C++) pointer to a memory location? Isn't `String::from("hello world")` allocated in the heap? Why can't Rust just return a reference (pointer) to that heap location then? I'm really confused by this point. – JohnTortugo Dec 28 '20 at 20:28
  • 2
    @JohnTortugo yes, references *are* like a pointer in many ways (and not, in others). If you saw a C function like `char *foo()`, do you free the returned data or not? `String` is effectively a struct with `(allocated_capacity, used_size, pointer_to_heap_allocation)`. – Shepmaster Dec 29 '20 at 12:41
  • Thanks, @Shepmaster. With `char *foo()` at least I have the option to [not] free if I need to keep the reference longer. – JohnTortugo Dec 29 '20 at 23:22
  • 3
    @JohnTortugo not really, because you don’t know *if* you can free it in the C code based on just the signature. Rust removes the ambiguity by splitting the two concepts into two types. – Shepmaster Dec 29 '20 at 23:42
  • Great answer @Shepmaster. But you mentioned that: > A static string will outlive any lifetime, so that's valid to substitute. But if that's true, why must there be at least one parameter to compare a static var to? I.e., it's not clear to me why not `fn hello_string() -> &str {` Thanks! – Serg Mar 11 '23 at 21:48
  • @Serg that function signature doesn't fit any of the [lifetime elision rules](https://doc.rust-lang.org/stable/book/ch10-03-lifetime-syntax.html#lifetime-elision), so the compiler doesn't know what lifetime to use. – Shepmaster Apr 14 '23 at 20:55
4

If you want to return a &str in Rust you have to add generic lifetime. Example:

fn hello_string<'life>() -> &'life str {
    return "hello world";
}

or,

fn hello_string<'life>(a: &'life str, b: &'life str) -> &'life str {
    return "hello world";
}

Here have a 3 rules.

  1. Each parameter that is a reference gets it's own lifetime parameter.
  2. If there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters.
  3. If there are multiple input lifetime parameters, but one of them is &self or &mut self the lifetime of self is assigned to all output lifetime parameters.
shariful islam
  • 389
  • 4
  • 18