The sticky note problem
You write a function to parse a configuration line. You create a String inside the function, extract the username, and try to return a &str pointing to that username. The compiler rejects the code. You think Rust is being pedantic. It's not. Rust is saving you from a dangling pointer that would crash your program or leak memory the moment the function returns.
In Python or JavaScript, you can return a reference to anything. The garbage collector tracks every reference and keeps the data alive as long as someone points to it. Rust has no garbage collector. Rust uses a deterministic ownership system. When a variable goes out of scope, its memory is freed immediately. If you return a reference to a local variable, you are returning a pointer to memory that is about to be reclaimed. Rust stops this at compile time.
Ownership and the drop bomb
Every value in Rust has exactly one owner. The owner is responsible for cleaning up the value when its scope ends. A scope is a block of code, like the body of a function. When the function returns, the scope ends. All local variables are dropped.
A reference is a pointer to data owned by someone else. It does not own the data. It just points to it. If the owner drops the data, the reference becomes invalid. Accessing an invalid reference causes undefined behavior. Undefined behavior means your program might crash, return garbage, or silently corrupt memory. Rust eliminates undefined behavior by refusing to compile code that creates invalid references.
Imagine you write a secret message on a sticky note. You hand the sticky note to a friend. They can read it. Now imagine you write the message on a whiteboard in your room, then hand your friend a piece of paper that says "Go to my room and read the whiteboard." If you erase the whiteboard before your friend gets there, they're looking at blank space. Rust refuses to let you hand out the "go to my room" note if you're going to erase the whiteboard immediately.
The compiler checks the lifetime of every reference. A lifetime is how long a reference is valid. If a reference escapes the scope of the data it points to, the compiler rejects the code. This check happens at compile time, so there is zero runtime overhead. You pay for safety once, when you build the binary.
The compiler says no
Here is the classic mistake. You create a String inside a function and try to return a reference to it.
fn get_greeting() -> &str {
// Create a new String on the heap.
// This String is owned by get_greeting.
let message = String::from("Hello, world!");
// Try to return a reference to message.
// The compiler rejects this immediately.
&message
}
The compiler throws E0515: "returns a value referencing data owned by the current function." The error message points to message and explains that the reference would outlive the data.
When get_greeting returns, the stack frame is popped. message is dropped. The heap memory allocated for the string is freed. If Rust allowed the reference, the caller would hold a pointer to freed memory. Accessing that pointer is undefined behavior. Rust prevents the binary from being built.
The fix depends on what you're trying to do. If the function creates new data, return the owned value. If the function extracts data from an argument, return a reference to the argument.
Returning owned data
When the function creates data that didn't exist before, the caller needs to take ownership. Return the owned type, not a reference.
fn get_greeting() -> String {
// Create a new String.
// The caller will own this String.
String::from("Hello, world!")
}
fn main() {
// Take ownership of the returned String.
let greeting = get_greeting();
println!("{}", greeting);
}
This works because the String is moved to the caller. The caller becomes the owner. The memory stays alive as long as the caller keeps the String. There is no dangling reference. The ownership chain is clear.
Returning owned values is the standard pattern for functions that generate new data. It allocates memory on the heap, but the allocation is necessary because the data must survive the function call. The caller can choose to drop the value early or keep it for the duration of the program.
Borrowing from arguments
When the function processes data passed by the caller, the caller already owns the data. You can return a reference to that data. The reference borrows from the argument, so it lives as long as the argument lives.
fn extract_username(log_line: &str) -> &str {
// log_line is borrowed from the caller.
// The caller owns the underlying data.
if let Some(pos) = log_line.find(':') {
// Return a slice of the input.
// The slice borrows from log_line.
// The slice lives as long as log_line.
&log_line[..pos]
} else {
log_line
}
}
fn main() {
let log = String::from("user:admin");
// log is owned by main.
// extract_username borrows from log.
let user = extract_username(&log);
println!("{}", user);
}
This works because the data lives outside the function. The reference returned by extract_username points to data owned by main. The lifetime of the return value is tied to the lifetime of the argument. The compiler infers this connection automatically.
The function signature fn extract_username(log_line: &str) -> &str is shorthand for fn extract_username<'a>(log_line: &'a str) -> &'a str. The lifetime parameter 'a ties the output reference to the input reference. The compiler ensures the output doesn't outlive the input. This is called lifetime elision. You rarely need to write explicit lifetimes for simple cases.
Static strings and literals
You might notice that returning a string literal works fine.
fn get_default() -> &'static str {
// String literals are embedded in the binary.
// They live for the entire program duration.
"default_value"
}
String literals have the lifetime 'static. They are stored in the read-only data segment of the executable. They never get dropped. You can return a reference to a static string from anywhere. The reference is always valid.
This is different from String::from("text"). The literal "text" is static. String::from("text") allocates a new buffer on the heap and copies the text. The buffer is owned by the local variable and gets dropped when the function returns.
Use &'static str for hardcoded constants. Use String for dynamic data. Don't confuse the two. The compiler distinguishes them by type and lifetime.
When the data must survive
Sometimes you need to return a reference, but the data is created inside the function. This happens when you're building a cache or a registry. The solution is to store the data in a container that outlives the function.
struct Cache {
entries: std::collections::HashMap<String, String>,
}
impl Cache {
fn get_or_insert(&mut self, key: &str, default: &str) -> &str {
// Check if the key exists.
if let Some(value) = self.entries.get(key) {
// Return a reference to the cached value.
// The value is owned by the Cache.
value.as_str()
} else {
// Insert a new value.
// The Cache owns the new String.
self.entries.insert(key.to_string(), default.to_string());
// Return a reference to the newly inserted value.
// This is safe because the Cache outlives the function.
self.entries.get(key).unwrap().as_str()
}
}
}
The Cache owns the data. The function returns a reference into the cache. The reference is valid as long as the cache is valid. The caller must ensure the cache lives long enough. This pattern is common in parsers, UI frameworks, and database drivers.
The key insight is that the data must be owned by something that outlives the reference. If the function creates the data, the function must store it in a long-lived container. You can't return a reference to a local variable. You can return a reference to a field of a struct passed as an argument.
Pitfalls and error codes
You'll encounter a few specific errors when working with references and lifetimes. Knowing the codes helps you diagnose issues quickly.
E0515 is the most common. "Returns a value referencing data owned by the current function." This means you're trying to return a reference to a local variable. Fix it by returning the owned value or borrowing from an argument.
E0517 says "cannot return reference to local variable." This is similar to E0515 but appears in slightly different contexts, like returning a reference to a temporary. The fix is the same. The data must outlive the function.
E0502 says "cannot borrow as mutable because it is also borrowed as immutable." This happens when you try to return a reference while also mutating the data. Rust prevents data races and aliasing. You can't have a mutable reference and an immutable reference at the same time. Fix it by restructuring the code to separate the borrow and the mutation.
E0505 says "cannot move out of because it is borrowed." This occurs when you try to move data that is currently referenced. The reference must be dropped before the data can be moved. Fix it by dropping the reference or cloning the data.
The compiler messages are usually precise. They point to the conflicting lines and explain the lifetime mismatch. Read the error carefully. The compiler is telling you exactly where the ownership chain breaks.
Convention: Cow for flexibility
When a function sometimes returns a reference and sometimes returns owned data, use Cow<str>. Cow stands for Clone on Write. It's an enum that can hold either a borrowed reference or an owned value.
use std::borrow::Cow;
fn process_input(input: &str) -> Cow<str> {
if input.is_empty() {
// Return owned data when input is invalid.
Cow::Owned(String::from("default"))
} else {
// Return borrowed data when input is valid.
// No allocation needed.
Cow::Borrowed(input)
}
}
This pattern avoids allocation when the input is sufficient. It allocates only when necessary. The caller can treat Cow<str> like a &str using the Deref trait. This is a standard convention in the Rust ecosystem for functions that might modify or replace input data.
Decision matrix
Use the owned String when the function creates new data and the caller needs to take responsibility for it. Return a &str reference when the function extracts a slice from an argument the caller already owns. Use Cow<str> when the function might return a slice of input or a newly allocated string, and you want to skip allocation when the input is sufficient. Reach for &'static str when the value is a hardcoded constant that lives for the entire program. Store data in a container and return a reference when the function creates data that must persist beyond the call, and the caller provides the storage.
Don't fight the drop. Return the owner. If the data dies here, the reference must die here too.