Lifetimes in functions in Rust - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify a lifetime parameter for the function.

Rust

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

Drag options to blanks, or click blank then click option'

A'z

B'a

C'static

D'b

Attempts:

3 left

💡 Hint

Common Mistakes

Forgetting to declare the lifetime parameter.

Using different lifetime names for input and output.

Using a lifetime on the parameter that is not linked to the output.

The lifetime parameter 'a is used to link the lifetime of the input x and the output reference.

2fill in blank

medium

Complete the code to declare the lifetime for both input parameters.

Rust

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

Drag options to blanks, or click blank then click option'

A&'a str

B&str

C&'static str

D&'b str

Attempts:

3 left

💡 Hint

Common Mistakes

Using &str without a lifetime.

Using a different lifetime like &'b str.

Using &'static str which is too restrictive.

Both input parameters must have the same lifetime 'a to ensure the output lifetime is valid.

3fill in blank

hard

Fix the error in the function signature by adding the correct lifetime to the return type.

Rust

fn first_word<'a>(s: &'a str) -> [1] {
    let bytes = s.as_bytes();
    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }
    &s[..]
}

Drag options to blanks, or click blank then click option'

AString

B&str

C&'static str

D&'a str

Attempts:

3 left

💡 Hint

Common Mistakes

Returning a reference without a lifetime.

Returning a String instead of a reference.

Using &'static str incorrectly.

The return type must have the same lifetime as the input reference to ensure safety.

4fill in blank

hard

Fill both blanks to correctly declare lifetimes for the function parameters and return type.

Rust

fn choose_first<'a, 'b>(x: &'a str, y: &'b str) -> [1] {
    x
}

fn choose_second<'a, 'b>(x: &'a str, y: &'b str) -> [2] {
    y
}

Drag options to blanks, or click blank then click option'

A&'a str

B&'b str

C&str

DString

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong lifetime for the return type.

Using &str without lifetime annotations.

Returning String instead of references.

The return type must match the lifetime of the reference returned from the function.

5fill in blank

hard

Fill all three blanks to correctly declare lifetimes and return a reference with the correct lifetime.

Rust

fn longest_with_announcement<'a>(x: &'a str, y: &'a str, ann: &str) -> [1] {
    println!("Announcement: {}", ann);
    if x.len() > y.len() {
        [2]
    } else {
        [3]
    }
}

Drag options to blanks, or click blank then click option'

A&'a str

B&'b str

Cx

Dy

Attempts:

3 left

💡 Hint

Common Mistakes

Not declaring lifetimes for the return type.

Returning values without matching lifetimes.

Using String instead of references.

The return type lifetime must match the lifetime of the returned reference. The function returns either x or y, so the lifetime must be declared accordingly.

Practice

1. What is the main purpose of lifetimes in Rust functions?

easy

A. To control thread execution order

B. To tell Rust how long references are valid

C. To define variable types explicitly

D. To manage memory allocation size

Solution

1. Step 1: Understand lifetimes concept

   Lifetimes specify how long references remain valid to prevent dangling pointers.

2. Step 2: Identify purpose in functions

   Functions use lifetimes to connect input and output references safely.

3. Final Answer:

   To tell Rust how long references are valid -> Option B

4. Quick Check:

   Lifetimes = reference validity [OK]

Hint: Lifetimes track reference validity duration [OK]

Common Mistakes:

• Confusing lifetimes with memory size
• Thinking lifetimes manage variable types
• Assuming lifetimes control threads

2. Which of the following is the correct syntax to declare a function with a lifetime parameter 'a that returns a reference with the same lifetime?

easy

A. fn example<'a>(x: &'a str) -> &'a str { x }

B. fn example(x: &str) -> &str { x }

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

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

Solution

1. Step 1: Identify lifetime parameter usage

   The lifetime 'a must be declared and used consistently in parameters and return type.

2. Step 2: Check each option's correctness

   fn example<'a>(x: &'a str) -> &'a str { x } correctly declares 'a and uses it for input and output references.

3. Final Answer:

   fn example<'a>(x: &'a str) -> &'a str { x } -> Option A

4. Quick Check:

   Lifetime declared and used consistently [OK]

Hint: Declare and use lifetime parameter consistently [OK]

Common Mistakes:

• Omitting lifetime declaration
• Using lifetime only in return type
• Using lifetime only in parameter

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

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

fn main() {
    let s1 = String::from("apple");
    let s2 = String::from("banana");
    let result = longest(&s1, &s2);
    println!("{}", result);
}

medium

A. Runtime error

B. apple

C. Compilation error due to lifetimes

D. banana

Solution

1. Step 1: Understand function logic

   The function returns the longer string slice between x and y.

2. Step 2: Compare string lengths

   "apple" has 5 letters, "banana" has 6 letters, so "banana" is longer.

3. Final Answer:

   banana -> Option D

4. Quick Check:

   Longest string = banana [OK]

Hint: Compare lengths, return longer string slice [OK]

Common Mistakes:

• Assuming compilation error due to lifetimes
• Confusing which string is longer
• Expecting runtime error

4. Identify the error in this Rust function and how to fix it:

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();
    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }
    &s
}

medium

A. Missing lifetime annotation on function signature

B. Incorrect byte comparison syntax

C. Return type should be String, not &str

D. Function should take String, not &str

Solution

1. Step 1: Analyze function signature

   The function returns a reference to a slice of the input string, so lifetimes must be connected.

2. Step 2: Identify missing lifetime annotation

   Without lifetime 'a, Rust cannot ensure the returned reference is valid as long as input.

3. Final Answer:

   Missing lifetime annotation on function signature -> Option A

4. Quick Check:

   Lifetime needed for input and output references [OK]

Hint: Add lifetime to input and output references [OK]

Common Mistakes:

• Ignoring lifetime errors
• Changing return type unnecessarily
• Confusing byte comparison syntax

5. Given two string slices with different lifetimes, how can you write a function that returns the longer slice without lifetime errors?

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

hard

A. Use different lifetime parameters for inputs and output

B. Return a String instead of a reference to avoid lifetimes

C. Add a single lifetime parameter 'a to both inputs and output: fn longest<'a>(x: &'a str, y: &'a str) -> &'a str

D. Remove references and pass owned Strings

Solution

1. Step 1: Understand lifetime mismatch

   Without lifetime annotations, Rust cannot guarantee output reference lives as long as inputs.

2. Step 2: Use a single lifetime parameter

   Declaring 'a for both inputs and output ties their lifetimes together, resolving errors.

3. Final Answer:

   Add a single lifetime parameter 'a to both inputs and output: fn longest<'a>(x: &'a str, y: &'a str) -> &'a str -> Option C

4. Quick Check:

   Single lifetime parameter ties input/output lifetimes [OK]

Hint: Use one lifetime parameter for all references [OK]

Common Mistakes:

• Using different lifetimes for inputs and output
• Returning owned String unnecessarily
• Removing references instead of fixing lifetimes