Variable lifetime basics in Rust - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Rust code with lifetimes?

Consider the following Rust code that uses references with explicit lifetimes. What will it print?

Rust

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

fn main() {
    let string1 = String::from("apple");
    let string2 = "banana";
    let result = longest(string1.as_str(), string2);
    println!("{}", result);
}

A banana

B apple

C Compilation error due to lifetime mismatch

D applebanana

💡 Hint

Think about which string slice is longer and how lifetimes ensure safety.

The function longest returns the longer string slice. "banana" is longer than "apple", so it prints "banana".

❓ Predict Output

intermediate

What error does this Rust code produce?

Look at this Rust code snippet. What error will the compiler show?

Rust

fn main() {
    let r;
    {
        let x = 5;
        r = &x;
    }
    println!("{}", r);
}

A Compilation error: cannot assign twice to immutable variable

B Prints 5

C Compilation error: borrowed value does not live long enough

D Runtime error: use after free

💡 Hint

Check the scope of x and the reference r.

The variable x is dropped at the end of the inner block, but r tries to reference it outside that scope. Rust prevents this with a compile-time error.

🔧 Debug

advanced

Why does this Rust code fail to compile due to lifetimes?

Identify the reason this Rust code does not compile and what lifetime rule it violates.

Rust

fn get_str<'a>() -> &'a str {
    let s = String::from("hello");
    &s
}

fn main() {
    let result = get_str();
    println!("{}", result);
}

A Returns reference to a local variable that is dropped, causing dangling reference

B Missing lifetime annotation on function parameter

C Cannot return a reference without specifying 'static lifetime

D Function should return String, not &str

💡 Hint

Think about the lifetime of s inside the function.

The function returns a reference to s, which is dropped when the function ends. This causes a dangling reference, which Rust forbids.

📝 Syntax

advanced

Which option correctly declares a function with lifetime parameters?

Choose the correct Rust function signature that returns the longer of two string slices with proper lifetime annotations.

A fn longest(x: &str, y: &str) -> &str

B fn longest<'a>(x: &'a str, y: &'a str) -> &'a str

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

D fn longest(x: &'a str, y: &'a str) -> &'a str

💡 Hint

Remember to declare lifetime parameters before using them in references.

Option B correctly declares a single lifetime parameter 'a and uses it consistently for both parameters and the return type.

🚀 Application

expert

How many items does this Rust code store in the vector?

Given this Rust code using references with lifetimes, how many items will be stored in the vector vec after execution?

Rust

fn main() {
    let mut vec = Vec::new();
    {
        let s = String::from("hello");
        vec.push(&s);
    }
    println!("{}", vec.len());
}

A 1

B 0

C Runtime panic due to invalid reference

D Compilation error due to lifetime mismatch

💡 Hint

Consider the lifetime of s and the reference stored in the vector.

The reference to s is pushed into the vector, but s is dropped at the end of the inner block. Rust prevents storing a reference that may become invalid, causing a compile-time error.

Practice

1. What does a variable lifetime in Rust describe?

easy

A. How long a reference remains valid in the program

B. The size of a variable in memory

C. The number of times a variable is used

D. The type of a variable

Solution

1. Step 1: Define lifetime and evaluate options

   In Rust, lifetime refers to how long a reference is valid and safe to use. Only 'How long a reference remains valid in the program' correctly describes it; B is size, C is usage count, D is type.

2. Final Answer:

   How long a reference remains valid in the program -> Option A

3. Quick Check:

   Lifetime = reference validity duration [OK]

Hint: Lifetime means reference validity duration [OK]

Common Mistakes:

• Confusing lifetime with variable size
• Thinking lifetime counts usage times
• Mixing lifetime with variable type

2. Which of the following is the correct syntax to declare a function with a lifetime parameter 'a for a reference argument in Rust?

easy

A. fn example(x: &i32) -> &i32 { x }

B. fn example(x: &i32<'a>) -> &i32<'a> { x }

C. fn example<'a>(x: &'a i32) -> &'a i32 { x }

D. fn example<'a>(x: &i32) -> &'a i32 { x }

Solution

1. Step 1: Verify lifetime annotation syntax and check options

   Rust requires lifetime parameters declared with 'a before the function and used in references as &'a i32. A correctly declares and uses 'a for input/output. B misplaces after type, C lacks annotations, D misses on input.

2. Final Answer:

   fn example<'a>(x: &'a i32) -> &'a i32 { x } -> Option C

3. Quick Check:

   Lifetime syntax = fn name<'a>(x: &'a Type) -> &'a Type [OK]

Hint: Declare lifetime before function, use on references [OK]

Common Mistakes:

• Placing lifetime after type instead of before
• Omitting lifetime on input or output references
• Using lifetime without declaring it

3. What will be the output of this Rust code snippet?

fn main() {
    let mut r;
    {
        let x = 5;
        r = &x;
    }
    println!("{}", r);
}

medium

A. 5

B. Compilation error due to lifetime mismatch

C. 0

D. Runtime panic

Solution

1. Step 1: Analyze scopes and reference lifetime

   x goes out of scope at end of inner block, but r references it and lives longer, violating Rust's lifetime rules, resulting in compilation error.

2. Final Answer:

   Compilation error due to lifetime mismatch -> Option B

3. Quick Check:

   Reference lifetime must not outlive data [OK]

Hint: References can't outlive the data they point to [OK]

Common Mistakes:

• Assuming code prints 5 without error
• Expecting runtime panic instead of compile error
• Ignoring inner block scope

4. Identify the error in this Rust function related to lifetimes:

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

medium

A. Missing lifetime annotations on parameters and return type

B. Using &str instead of String

C. Function should return usize instead of &str

D. No error, code is correct

Solution

1. Step 1: Examine function signature and Rust lifetime rules

   The function returns a reference to one of the inputs without lifetime annotations, preventing Rust from verifying safety. Annotations like <'a> are required on params and return.

2. Final Answer:

   Missing lifetime annotations on parameters and return type -> Option A

3. Quick Check:

   Return references need lifetime annotations [OK]

Hint: Add lifetime annotations when returning references [OK]

Common Mistakes:

• Thinking &str vs String causes error
• Believing function should return length
• Assuming no error without lifetimes

5. Given this struct and function, which lifetime annotation is correct to ensure the reference inside Holder is valid?

struct Holder<'a> {
    value: &'a str,
}

fn create_holder(s: &str) -> Holder {
    Holder { value: s }
}

hard

A. fn create_holder(s: &'a str) -> Holder<'a> { Holder { value: s } }

B. fn create_holder(s: &str) -> Holder { Holder { value: s } }

C. fn create_holder<'a>(s: &str) -> Holder<'a> { Holder { value: s } }

D. fn create_holder<'a>(s: &'a str) -> Holder<'a> { Holder { value: s } }

Solution

1. Step 1: Match function signature to struct lifetime parameter

   Holder<'a> ties value's lifetime to 'a. Function must declare 'a, use on s: &'a str, return Holder<'a>. D correct; A lacks fn 'a decl, B/C mismatch lifetimes.

2. Final Answer:

   fn create_holder<'a>(s: &'a str) -> Holder<'a> { Holder { value: s } } -> Option D

3. Quick Check:

   Function lifetimes must match struct lifetimes [OK]

Hint: Match function and struct lifetimes exactly [OK]

Common Mistakes:

• Omitting lifetime on function signature
• Using lifetime only on return or input, not both
• Assuming struct lifetime is optional