> ## 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 Annotation
Lifetime annotations are explicit, compile-time generic parameters that describe the relationship between the scopes of multiple references. They do not alter the runtime duration of a value; rather, they instruct the Rust borrow checker on how to validate that references remain valid for a required duration, ensuring memory safety by preventing dangling pointers.
Because lifetimes are a type of generic parameter, they must be declared inside angle brackets `<>` before they can be used. The syntax utilizes an apostrophe (`'`) followed by a lowercase identifier.
```rust theme={"dark"}
&i32 // A reference with an implicit (elided) lifetime
&'a i32 // A reference with an explicit lifetime 'a
&'a mut i32 // A mutable reference with an explicit lifetime 'a
```
## Function Signatures
When a function takes or returns references, lifetime annotations map the input lifetimes to the output lifetimes.
```rust theme={"dark"}
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
// ...
}
```
In this signature, `<'a>` declares the lifetime. By applying `'a` to both parameters and the return type, the annotation dictates a strict contract: the returned reference will be valid only for the length of the *shortest* scope among the inputs `x` and `y`.
## Struct Definitions
If a struct holds a reference, the struct itself must be annotated with a lifetime. This enforces that the struct instance cannot outlive the data it references.
```rust theme={"dark"}
struct Context<'a> {
config: &'a str,
}
```
## Implementation Blocks
When implementing methods for a struct that contains lifetime annotations, the lifetimes must be declared on the `impl` block so they can be used in the struct type and its methods.
```rust theme={"dark"}
impl<'a> Context<'a> {
fn get_config(&self) -> &'a str {
self.config
}
}
```
## Lifetime Elision Rules
To reduce boilerplate, the Rust compiler applies three deterministic rules (Lifetime Elision) to infer lifetimes automatically. If the compiler cannot resolve all lifetimes after applying these rules, it throws a compilation error requiring explicit annotations.
1. **Input Rule:** Each elided lifetime in input parameters becomes a distinct lifetime parameter.
*(e.g., `fn foo(x: &i32, y: &i32)` becomes `fn foo<'a, 'b>(x: &'a i32, y: &'b i32)`)*
2. **Single Input Rule:** If there is exactly one input lifetime parameter, that lifetime is assigned to all elided output lifetimes.
*(e.g., `fn foo(x: &i32) -> &i32` becomes `fn foo<'a>(x: &'a i32) -> &'a i32`)*
3. **Method Rule:** If there are multiple input lifetime parameters, but one of them is `&self` or `&mut self`, the lifetime of `self` is assigned to all elided output lifetimes.
## Lifetime Bounds (Subtyping)
Lifetimes can be constrained relative to one another using bounds, similar to trait bounds. This is known as lifetime subtyping.
```rust theme={"dark"}
struct Parser<'c, 's: 'c> {
context: &'c Context<'s>,
}
```
The syntax `'s: 'c` is read as "lifetime `'s` outlives `'c`". It guarantees to the compiler that the reference to the data (`'s`) will live at least as long as the context (`'c`) holding it.
## Special Lifetimes
* `'static`: Denotes a reference that can live for the entire duration of the program. String literals (`&'static str`) possess this lifetime inherently because their data is stored directly in the binary's read-only data segment.
* `'_`: The anonymous lifetime. It is used to explicitly tell the compiler to infer the lifetime using elision rules, or to indicate in a trait implementation that a lifetime is present but its specific identifier is irrelevant to the current scope.
Tired of Poor Rust Skills? Fix That With Deep Grasping!
Learn More
