2 ms·

From what I hear, making "intrusive linked lists which lend out &mut" sound is an unsolved problem: https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a

• oconnor663 5y ago
  Oh yeah for sure. Even if you make sure your lists don't have any cycles, it's also possible for a given object to be on multiple different lists. Sometimes that's the whole point of the intrusive approach. But if you're accessible from multiple lists, there's no way a list can meet the uniqueness requirements of &mut. I guess you have two options: 1. Make the whole list API unsafe, so that the only way to expose a safe API on top of it is to make the list an internal implementation detail. 2. Take the Rc<RefCell<T>> or Arc<Mutex<T>> approach, where each element effectively has its own lock. Of course in high-performance code this is usually too expensive, and in any code calling .borrow() or .lock() all over the place is annoying.