Lifetime elision rules in Rust - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a function that returns a reference to the first element of a slice.

Rust

fn first_element(slice: &[i32]) -> &[1] {
    &slice[0]
}

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

Abool

Bstr

Ci32

Dchar

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different type than the slice element type.

Forgetting to use a reference in the return type.

The function returns a reference to an i32 because the slice contains i32 elements.

2fill in blank

medium

Complete the function signature to use lifetime elision correctly for a function returning the longer of two string slices.

Rust

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

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

AString

Bstr

Cchar

Dusize

Attempts:

3 left

💡 Hint

Common Mistakes

Using String instead of str in the return type.

Omitting the lifetime parameter in the return type.

The function returns a string slice reference, so the return type is &'a str.

3fill in blank

hard

Fix the error in the function signature by adding the correct lifetime elision for a method returning a reference to self's name.

Rust

impl Person {
    fn name(&[1] self) -> &str {
        &self.name
    }
}

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

A'_

B'a

C'static

D'self

Attempts:

3 left

💡 Hint

Common Mistakes

Using undefined lifetime parameters like 'a or 'self.

Using 'static which is too restrictive.

Using the anonymous lifetime '_ allows Rust to apply lifetime elision rules automatically for method receivers.

4fill in blank

hard

Fill both blanks to complete the function that returns a reference to the longer string slice using lifetime elision rules.

Rust

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

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

Astr

B>

C<

DString

Attempts:

3 left

💡 Hint

Common Mistakes

Using String instead of str as return type.

Using '<' instead of '>' in the length comparison.

The return type is a string slice reference 'str', and the comparison uses '>' to check which string is longer.

5fill in blank

hard

Fill all three blanks to complete the struct and impl that uses lifetime elision rules for a reference field and a method returning that reference.

Rust

struct ImportantExcerpt<'a> {
    part: &[1] [2]
}

impl<'a> ImportantExcerpt<'a> {
    fn level(&[3] self) -> i32 {
        3
    }
}

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

Astr

B'a

C'_

DString

Attempts:

3 left

💡 Hint

Common Mistakes

Using String instead of str for the field type.

Omitting the lifetime parameter for the reference field.

Using incorrect lifetime annotations for self.

The struct field is a reference to a string slice with lifetime 'a, and the method uses the anonymous lifetime '_' for self.

Practice

1. Which of the following best describes the purpose of Rust's lifetime elision rules?

easy

A. To let Rust automatically fill in lifetimes in common cases without explicit annotations.

B. To force the programmer to always write explicit lifetime annotations.

C. To remove all lifetimes from the code for simplicity.

D. To allow Rust to ignore lifetime errors during compilation.

Solution

1. Step 1: Understand lifetime elision rules

   Lifetime elision rules help Rust guess lifetimes automatically in common cases.

2. Step 2: Compare options

   Only To let Rust automatically fill in lifetimes in common cases without explicit annotations. correctly states that Rust fills in lifetimes automatically without needing explicit annotations in many cases.

3. Final Answer:

   To let Rust automatically fill in lifetimes in common cases without explicit annotations. -> Option A

4. Quick Check:

   Lifetime elision = automatic lifetime filling [OK]

Hint: Elision means Rust guesses lifetimes for you [OK]

Common Mistakes:

• Thinking Rust always requires explicit lifetimes
• Believing lifetimes are removed entirely
• Assuming Rust ignores lifetime errors

2. Which of the following function signatures correctly uses lifetime elision rules in Rust?

easy

A. fn first_word<'a>(s: &'a str) -> &'a str

B. fn first_word(s: &str) -> &str

C. fn first_word(s: &str) -> &'a str

D. fn first_word<'a>(s: &str) -> &str

Solution

1. Step 1: Recall lifetime elision rules for functions

   When a function has one input lifetime, Rust assumes the output lifetime is the same as the input.

2. Step 2: Analyze options

   fn first_word(s: &str) -> &str uses no explicit lifetimes but is valid due to elision. fn first_word<'a>(s: &'a str) -> &'a str is explicit but correct. fn first_word(s: &str) -> &'a str is invalid because it uses an undefined lifetime in output. fn first_word<'a>(s: &str) -> &str mixes explicit and implicit lifetimes incorrectly.

3. Final Answer:

   fn first_word(s: &str) -> &str -> Option B

4. Quick Check:

   One input ref means output ref gets same lifetime [OK]

Hint: One input ref means output ref lifetime is same [OK]

Common Mistakes:

• Using undefined lifetime parameters
• Mixing explicit and implicit lifetimes incorrectly
• Forgetting elision rules allow omission

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

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

fn main() {
    let string1 = String::from("apple");
    let string2 = String::from("banana");
    let result = longest(&string1, &string2);
    println!("Longest string is: {}", result);
}

medium

A. Runtime error due to dangling reference

B. Longest string is: banana

C. Longest string is: apple

D. Compilation error due to missing lifetime annotations

Solution

1. Step 1: Check lifetime elision rules for the function

   The function takes two input references (x and y) and returns a reference. Elision rules do not apply when there are multiple input lifetimes and an output lifetime; Rust cannot determine which input lifetime to use for the output.

2. Step 2: Confirm compilation behavior

   This results in a compilation error: `missing lifetime specifier`. The code does not compile.

3. Final Answer:

   Compilation error due to missing lifetime annotations -> Option D

4. Quick Check:

   Multiple input refs need explicit lifetimes [OK]

Hint: Two input refs to output requires explicit lifetimes [OK]

Common Mistakes:

• Thinking elision allows compilation with multiple input refs
• Believing it returns the longer string
• Confusing runtime errors with lifetime errors

4. Identify the error in the following Rust function related to lifetime elision rules:

fn invalid_ref(x: &str, y: &str) -> &str {
    let result = String::from("hello");
    &result
}

medium

A. The function returns a reference to a local variable that will be dropped.

B. The function is missing lifetime annotations on parameters.

C. The function should return a String, not a reference.

D. The function should use explicit lifetime annotations to compile.

Solution

1. Step 1: Analyze the returned reference

   The function returns a reference to 'result', a local String created inside the function.

2. Step 2: Understand lifetime rules and error

   'result' is dropped when the function ends, so returning a reference to it causes a dangling reference error.

3. Final Answer:

   The function returns a reference to a local variable that will be dropped. -> Option A

4. Quick Check:

   Returning local reference causes dangling pointer [OK]

Hint: Never return reference to local variable [OK]

Common Mistakes:

• Thinking missing lifetime annotations cause this error
• Believing explicit lifetimes fix dangling references
• Confusing return type with ownership

5. Given the following struct and method, which lifetime elision rule applies to the method's signature?

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

impl<'a> Container<'a> {
    fn get_value(&self) -> &str {
        self.value
    }
}

What lifetime does Rust assign to the return value of get_value by elision?

hard

A. The return value has an unrelated anonymous lifetime.

B. The return value has the lifetime 'a from the struct definition.

C. The return value has the same lifetime as &self (the method receiver).

D. The return value has a static lifetime.

Solution

1. Step 1: Identify lifetime elision rules for methods

   Rule 3 states that if there is a &self or &mut self parameter, the output lifetime is the same as self's lifetime.

2. Step 2: Apply rule to method signature

   The method takes &self and returns &str without explicit lifetime. Rust assigns the return lifetime to match &self's lifetime.

3. Final Answer:

   The return value has the same lifetime as &self (the method receiver). -> Option C

4. Quick Check:

   Method output lifetime = &self lifetime [OK]

Hint: Method output lifetime matches &self lifetime by elision [OK]

Common Mistakes:

• Confusing struct lifetime with method output lifetime
• Assuming static lifetime without reason
• Ignoring elision rule for &self receiver