Slice lifetime basics in Rust - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Rust code with slice lifetimes?

Consider the following Rust code. What will it print when run?

Rust

fn main() {
    let s = String::from("hello");
    let slice: &str = &s[0..2];
    println!("{}", slice);
}

A he

B hello

C h

D Compilation error due to lifetime

💡 Hint

Remember that slices borrow part of the original string and lifetimes ensure the original data lives long enough.

The slice &s[0..2] borrows the first two characters of the string "hello", which are 'h' and 'e'. So it prints "he".

❓ Predict Output

intermediate

What error does this Rust code produce related to slice lifetimes?

Analyze this Rust code. What error will the compiler show?

Rust

fn get_slice() -> &str {
    let s = String::from("world");
    &s[1..4]
}

fn main() {
    println!("{}", get_slice());
}

A error: `s` does not live long enough

B prints "orl"

C error: mismatched types

D compiles and prints "world"

💡 Hint

The function returns a reference to a local variable that is dropped at the end of the function.

The string `s` is created inside the function and dropped when the function ends. Returning a slice referencing it causes a lifetime error.

🔧 Debug

advanced

Why does this Rust code fail to compile due to slice lifetime?

Identify the reason for the compilation failure in this Rust code snippet.

Rust

fn main() {
    let r;
    {
        let s = String::from("hello");
        r = &s[0..3];
    }
    println!("{}", r);
}

A r is not initialized before use; runtime panic

B r references s which is dropped before println!; lifetime error

C s is moved into r causing ownership error

D No error; prints "hel"

💡 Hint

Check when the variable `s` goes out of scope compared to `r`.

The variable `s` is dropped at the end of the inner block, but `r` still references it outside that block, causing a lifetime error.

❓ Predict Output

advanced

What is the output of this Rust code with explicit lifetimes?

Given this Rust function with explicit lifetime annotations, 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("abcd");
    let string2 = "xyz";
    let result = longest(&string1, string2);
    println!("{}", result);
}

A Runtime panic

B xyz

C Compilation error due to lifetime mismatch

D abcd

💡 Hint

The function returns the longer string slice with the same lifetime as inputs.

The string "abcd" is longer than "xyz", so the function returns "abcd" and prints it.

🧠 Conceptual

expert

How do Rust slice lifetimes prevent dangling references?

Which statement best explains how Rust slice lifetimes help avoid dangling references?

A They use garbage collection to free unused slices safely.

B They automatically copy data to prevent references from becoming invalid.

C They ensure slices cannot outlive the data they reference by enforcing lifetime constraints at compile time.

D They allow mutable and immutable slices to coexist without restrictions.

💡 Hint

Think about how Rust checks references before running the program.

Rust uses lifetimes to check at compile time that references do not outlive the data they point to, preventing dangling references.

Practice

1. What does a slice lifetime in Rust indicate?
fn example<'a>(slice: &'a [i32]) {}

easy

A. How long the slice reference is valid in the program

B. The size of the slice in memory

C. The number of elements in the slice

D. The type of elements inside the slice

Solution

1. Step 1: Understand what a lifetime means in Rust

   Lifetimes tell Rust how long a reference is valid to prevent using invalid data.

2. Step 2: Apply this to a slice reference

   The lifetime on a slice reference means how long the slice can be safely used.

3. Final Answer:

   How long the slice reference is valid in the program -> Option A

4. Quick Check:

   Slice lifetime = reference validity [OK]

Hint: Lifetimes track reference validity duration [OK]

Common Mistakes:

• Confusing lifetime with size or length
• Thinking lifetime is about element type
• Ignoring lifetime annotations on references

2. Which of the following is the correct syntax to declare a function that takes a slice with a lifetime parameter?

fn process_slice(____) {}

easy

A. &'a [i32]

B. &'a [i32];

C. &[i32]

D. &[i32]'a

Solution

1. Step 1: Recall lifetime syntax for references

   Lifetimes are written as &'a before the type to indicate the lifetime of the reference.

2. Step 2: Check each option

   &'a [i32] correctly places &'a before the slice type [i32]. &[i32] misses lifetime, &'a [i32]; has an extra semicolon, &[i32]'a places lifetime incorrectly.

3. Final Answer:

   &'a [i32] -> Option A

4. Quick Check:

   Lifetime syntax = &'a [type] [OK]

Hint: Lifetimes go right after & before type [OK]

Common Mistakes:

• Putting lifetime after the type
• Adding extra semicolons inside parameters
• Omitting lifetime when needed

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

fn get_first<'a>(slice: &'a [i32]) -> &'a i32 {
    &slice[0]
}

fn main() {
    let numbers = vec![10, 20, 30];
    let first = get_first(&numbers);
    println!("{}", first);
}

medium

A. 20

B. 10

C. Compilation error due to lifetime mismatch

D. Runtime panic

Solution

1. Step 1: Understand the function behavior

   The function returns a reference to the first element of the slice, which is 10.

2. Step 2: Check lifetime correctness and usage

   The lifetime 'a ensures the returned reference is valid as long as the input slice is valid. The vector lives long enough, so no error.

3. Final Answer:

   10 -> Option B

4. Quick Check:

   Returned first element = 10 [OK]

Hint: Returned slice element matches first index [OK]

Common Mistakes:

• Thinking lifetime causes compile error here
• Confusing element values
• Expecting runtime panic without reason

4. Identify the error in this Rust code snippet:

fn invalid<'a>() -> &'a [i32] {
    let data = vec![1, 2, 3];
    &data[..]
}

medium

A. Missing lifetime annotation on data

B. Syntax error in slice syntax

C. The function returns a reference to data that will be dropped

D. No error, code is correct

Solution

1. Step 1: Analyze the function return and data lifetime

   The function returns a slice reference with lifetime 'a, but data is created inside the function and dropped when it ends.

2. Step 2: Understand why this causes an error

   Returning a reference to local data is invalid because the data won't live long enough, causing a dangling reference.

3. Final Answer:

   The function returns a reference to data that will be dropped -> Option C

4. Quick Check:

   Returning local reference = error [OK]

Hint: Never return reference to local variable [OK]

Common Mistakes:

• Assuming lifetime annotation fixes local data drop
• Ignoring ownership rules
• Thinking slice syntax is wrong

5. Given this function that returns a slice from two input slices, which lifetime annotation is correct to ensure safety?

fn longest_slice<'a>(x: &'a [i32], y: &'a [i32]) -> &____ [i32] {
    if x.len() > y.len() { x } else { y }
}

hard

A. 'a + 'b

B. 'b

C. 'static

D. 'a

Solution

1. Step 1: Understand the function's return lifetime

   The function returns a slice that could come from either input slice, both sharing lifetime 'a.

2. Step 2: Use shared lifetime for safety

   The correct lifetime for the return is 'a, matching the lifetime of both input slices.

3. Final Answer:

   'a -> Option D

4. Quick Check:

   Return lifetime = 'a of inputs [OK]

Hint: Return lifetime must cover both inputs [OK]

Common Mistakes:

• Choosing only one input lifetime
• Using 'static without reason
• Ignoring lifetime intersection rules