> ## Documentation Index > Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt > Use this file to discover all available pages before exploring further. # Rust Lifetime Elision Lifetime elision is a compiler mechanism in Rust that automatically infers and assigns lifetime parameters to references in function and method signatures based on a set of deterministic rules. It allows developers to omit explicit lifetime annotations in unambiguous borrowing patterns without compromising the borrow checker's strict memory safety guarantees. The Rust compiler evaluates elision by categorizing lifetimes into two groups: * **Input lifetimes:** Lifetimes associated with the parameters of a function or method. * **Output lifetimes:** Lifetimes associated with the return type of a function or method. During compilation, the compiler applies three specific rules to function signatures lacking explicit lifetime annotations. If the compiler can resolve all output lifetimes after applying these rules, the signature is accepted. If any output lifetimes remain ambiguous, compilation fails, and explicit annotations are required. ## The Three Rules of Lifetime Elision **Rule 1: Distinct Input Lifetimes** The compiler assigns a distinct, unique lifetime parameter to each elided lifetime in an input position. ```rust theme={"dark"} // Written syntax (Elided) fn process_strings(s1: &str, s2: &str) { unimplemented!() } ``` ```rust theme={"dark"} // Compiler expansion fn process_strings<'a, 'b>(s1: &'a str, s2: &'b str) { unimplemented!() } ``` **Rule 2: Single Input Lifetime** If there is exactly one input lifetime parameter (whether explicitly annotated or elided), that specific lifetime is automatically assigned to all elided output lifetimes. ```rust theme={"dark"} // Written syntax (Elided) fn extract_substring(s: &str) -> &str { unimplemented!() } ``` ```rust theme={"dark"} // Compiler expansion // Rule 1 assigns 'a to the input. Rule 2 assigns 'a to the output. fn extract_substring<'a>(s: &'a str) -> &'a str { unimplemented!() } ``` **Rule 3: Method Receiver Lifetimes (`&self` or `&mut self`)** If there are multiple input lifetime parameters, but one of them is a reference to the method receiver (`&self` or `&mut self`), the lifetime of `self` is assigned to all elided output lifetimes. This rule specifically facilitates ergonomic method definitions in `impl` blocks. ```rust theme={"dark"} struct Buffer { data: String, } impl Buffer { // Written syntax (Elided) fn get_part(&self, prefix: &str) -> &str { unimplemented!() } } ``` ```rust theme={"dark"} struct Buffer { data: String, } impl Buffer { // Compiler expansion // Rule 1 assigns 'a to &self and 'b to prefix. // Rule 3 assigns 'a (the lifetime of self) to the output. fn get_part<'a, 'b>(&'a self, prefix: &'b str) -> &'a str { unimplemented!() } } ``` ## Elision Failure If the compiler exhausts all three rules and there are still output lifetimes that have not been assigned a definitive lifetime, the elision process fails. This typically occurs when a function takes multiple references and returns a reference, but does not take a `self` parameter. ```rust theme={"dark"} // Compilation Error: Missing lifetime specifier // Rule 1 assigns 'a to x and 'b to y. // Rule 2 does not apply (multiple inputs). // Rule 3 does not apply (no self parameter). // The output lifetime cannot be deterministically inferred. // fn longest(x: &str, y: &str) -> &str { unimplemented!() } // Resolution requires explicit annotation by the developer: fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { unimplemented!() } ```

Tired of Poor Rust Skills? Fix That With Deep Grasping! Learn More