Lifetime elision rules in Rust - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Rust code with lifetime elision?

Consider the following Rust function using lifetime elision rules. What will be printed when calling print_first_word?

Rust

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[..]
}

fn print_first_word() {
    let sentence = String::from("hello world");
    let word = first_word(&sentence);
    println!("{}", word);
}

fn main() {
    print_first_word();
}

A hello world

B world

C hello

D Compilation error due to missing lifetime annotations

💡 Hint

Remember that Rust applies lifetime elision rules to functions with references. The returned reference lifetime is tied to the input reference.

The function first_word returns a slice of the input string up to the first space. The lifetime elision rules allow omitting explicit lifetime annotations because the output lifetime is tied to the input reference &str. The printed output is the first word: "hello".

❓ Predict Output

intermediate

What is the output of this Rust code with multiple references and elision?

Given the following Rust function, what will be printed when main runs?

Rust

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

fn main() {
    let string1 = String::from("short");
    let string2 = String::from("longer string");
    let result = longest(&string1, &string2);
    println!("{}", result);
}

A Compilation error due to missing lifetime annotations

B longer string

C short

D Runtime error due to dangling reference

💡 Hint

Functions with multiple input references returning a reference require explicit lifetime annotations unless elision rules apply.

The function longest takes two references and returns one of them. Rust's lifetime elision rules do not cover multiple input references returning a reference without explicit lifetime annotations. This code will not compile without specifying lifetimes.

🔧 Debug

advanced

Identify the lifetime error in this Rust code

Examine the following Rust code. What lifetime-related error will the compiler report?

Rust

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

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

A Error: mismatched types between String and &str

B Error: missing lifetime annotations on function signature

C No error, prints "hello"

D Error: returning reference to local variable `s` which will be dropped

💡 Hint

Think about the scope of the variable s and the returned reference.

The function tries to return a reference to a local variable s which is dropped when the function ends. This causes a lifetime error because the returned reference would be dangling.

📝 Syntax

advanced

Which function signature correctly uses lifetime elision rules?

Choose the function signature that compiles without explicit lifetime annotations and correctly applies Rust's lifetime elision rules.

A fn foo(x: &i32, y: &i32) -> &i32;

B fn foo(x: &i32) -> &i32;

C fn foo<'a>(x: &'a i32, y: &'a i32) -> &'a i32;

D fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32;

💡 Hint

Recall the three lifetime elision rules Rust applies to function signatures.

Rust applies lifetime elision rules as follows: if there is exactly one input lifetime, that lifetime is assigned to all output lifetimes. For multiple input lifetimes, explicit annotations are needed. Option B has one input reference and one output reference, so it compiles without explicit lifetimes.

🚀 Application

expert

How many lifetime annotations are needed in this struct and method?

Given this Rust code, how many explicit lifetime annotations are required for it to compile?

Rust

struct Container {
    value: &str,
}

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

fn main() {
    let s = String::from("data");
    let c = Container { value: &s };
    println!("{}", c.get_value());
}

A One - struct needs one lifetime parameter

B Three - struct, impl, and method all need lifetime parameters

C Two - struct and method both need lifetime parameters

D Zero - lifetime elision rules cover this code

💡 Hint

Struct fields with references require explicit lifetimes. Methods borrowing self usually do not need extra annotations if struct has lifetimes.

The struct Container has a reference field &str which requires an explicit lifetime parameter. The method get_value borrows &self and returns a reference tied to self, so lifetime elision applies and no extra annotation is needed there.