SlotMap attach/reattach, but without moving?

help
1

A SlotMap has detach/reattach methods, to help with certain access patterns. With the SecondaryMapyou can just use remove/insert for a similar effect.

// &mut self
let x = self.things.remove(id).unwrap();
x.layout(self); // Now I can pass a &mut to things because x is not borrowed
self.things.insert(id, x);

If value removed is small, it doesn't matter, but if the value is bigger it might be nice to have a way to use the same idea, but without moving the object in memory. Would it be possible?

let x = self.things.detach_ref(id); // x is &Thing, or &mut Thing
x.do_stuff(self);
self.things.revive(id);

The slotmap would have to know that one of its values was off limits. Maybe something like this already exists. Maybe that is basically re-inventing RefCell....

2

The problem is that x.do_stuff(self) could mutate self in arbitrary ways (assuming it takes an &mut parameter), which might invalidate the whole self.things and hence x too.

3

When I call detach(id), presumably the SlotMap knows not modify itself certain ways, because it knows not to reuse that slot. It waits for the reattach. Why can't a similar thing be done for detaching and handing out a reference?

4

x.do_stuff(self) could completely replace the SlotMap with a different one, as well as several other things that would invalidate the reference. The SlotMap has no opportunity to stop those things, because they are things that happen to the ownership of the SlotMap, not calling SlotMap-specific functions.

5

I said this before but I try say different. You don't need to remove and then insert the object. Just use the data inside the slotmap, the problem is that you aren't saving the key, you need that key to access in the slotmap.
// &mut self
let x = self.things.remove(id).unwrap();
x.layout(self); // Now I can pass a &mut to things because x is not borrowed
let y=self.things.insert(id, x);

y is the key

6

it's not possible.

suppose the detach has a signature of:

impl<K, V> SlotMap<K, V> {
    fn detach_re<'a>f(&'a mut self, id: K) -> &'??? mut V;
}

you want this operation to NOT move the value out of the slotmap, then what would the lifetime of the detached reference be, as shown in the '??? marker? the borrow checker only accept two options:

  • return a leaky 'static reference, which is unsound;
  • return a lifetime tied to the input slotmap 'a, in which case it just becomes Slotmpa::get_mut().
7

What would the signature for detach_ref look like? fn detach_ref<'this>(&'this self, id: K) -> Option<&'? V>... but what do you put in for the lifetime? You can't use 'this because then borrowck blocks your usage pattern, but you definitely can't use 'static.

EDIT: I see nerditation had the same thoughts as me, at the same time. :grinning_face_with_smiling_eyes:

8

Thanks all. I think I get it now. I was confusing two different things...

  1. Having a &mut to a slotmap (that isn't itself moving).
  2. Having a &mut to the owner of the slotmap. The slotmap itself could move or be de-allocated, etc.
9

I think your are confusing something more important the propose of slotmap, it is save the data, like a Vec, and your are trying to safe references, that is posible but not the objective of using slopmap

10

The methods detach/reattach exist on SlotMap for a reason. There is a real use case for this. But I have to get to a class so don't have time explain now. :slight_smile: Maybe later. I have a tree/graph of UI widgets. One of the things in my slotmaps is a Box that provides some customized behavior, like layout. And layout is recursive - it needs the slotmap again to get at data for other UI widgets...

11

the deeper problem is &mut in rust has very strong guarantees in the type system: it requires exclusiveness, not some weaker notion of "mutable". so what you have to do is change the signature of x.do_stuff(), so it does not take &mut Self. instead, it can take individual references of other fields that are disjoint with self.things.

this is a very common mistake, especially for users with OOP background. to demonstrate, suppose you have one large object (let's call it Parent), which "has-a" small object as a field (let's call it Child), it is impossible to call a Child method with a parameter of &mut Parent type on the field of a Parent object, because the child cannot borrow the parent exclusively, by definition:

struct Child {
    //
}
impl Child {
    fn do_stuff_with_parent(&mut self, parent: &mut Parent) {
        todo!()
    }
}
struct Parent {
    child: Child,
    //... other stuff
}
impl Parent {
    fn do_child_stuff(&mut self) {
        // IMPOSSIBLE to do in rust, reject by borrow checker
        self.child.do_stuff_with_parent(self)
    }
}
12

Actually, these are pretty much the same thing, when you are looking at what they permit. Both of them allow moving or deallocating the SlotMap.

13

I could have sworn I'd seen compiler errors before like "you can't move out of a mut ref". ?

Ah, maybe that's just if I'm not swapping it with some other value.

14

You can't move out of a reference with a plain deref operation, but you can use std::mem::swap, std::mem::replace, and std::mem::take.

15

That's what you'll see if you try to move something out of the owner too, actually.

#[derive(Debug, Default)]
struct Owner {
    map: SlotMap<String, i32>,
}

// This fails to compile
fn fail_to_move_with_an_indirect_mut(owner: &mut Owner) {
    let original: SlotMap<_, _> = owner.map;
    owner.map = SlotMap::default();
    println!("Inside `fail_to_move_with_an_indirect_mut`: {original:?}");
}

(Same error as if you had map: &mut SlotMap<_, _> and tried to move *map.)

The way you move it out of a &mut owner is to get a &mut SlotMap and then...

16

Are you also saying there should never be reason to to detach/remove an item from a SlotMap, call a function, and then reattach/insert the item again? (Like the code in the original post)

That seems unavoidable to me, for certain kinds of recursive algorithms on a tree. My tree has "parent" pointers, and some more experienced Rust devs recommended I use a SlotMap for this, and so far it seems to be working better than my previous attempts with Rc and rc::Weak.

17

no, I'm saying it's impossible to call a field's methods while passing &mut Self as argument: a child cannot borrow the parent exclusively.

in fact, if the API cannot be changed, the only way to make it work is you must (at least temporarily) move the child object out of the field of self, which is exactly what detatch/reattach is doing: moving the object ouf of the slotmap, which is a field.

it's simply impossible to "detach" without moving.

18

Thanks, I think I'm getting it. One of these days I'm going to understand Rust... :slight_smile: :man_facepalming:

19

everyone has been telling you this isn't possible.
they are somewhat right, but also very wrong. this is possible, but with caveats.
what you need to do is have a different type, representing a mutable reference to a SlotMap with one or more detached elements.
this new types would allow certain methods on the SlotMap, and disallow others.
here is how it would look like.


struct DetachableSlotMap<'a, K, V>  {
  src : &'a mut SlotMap<K,V>, 
   detached : Vec<K>
}

impl <K : Key, V> SlotMap<K,V>  {
   fn detachable(&mut self) -> WithDetached<'_, K, V> {}
}

impl <'a, K : Key, V> DetachableSlotMap<'a, K,V>  {
   fn detach_in_place(&mut self) -> Option<&'a mut V> {}
}

there are potentially aliasing issues that would need to be ironed out, but nothing impossible.
the the code could look like

let things = self.things.detachable();
let x : &mut V = things.detach_in_place(id).unwrap();
// do stuff with_things and x at the same time
drop(things); // reattaches everything that was detached

but if you have a struct with a SlotMap field like things in your example, you can't borrow all the struct and x mutacbly at the same time as it would allow you to destroy the SlotMap while x exists

20

You'd have to jump some safety hoops to get detach_in_place to have the correct signature, and I'm not sure they're sound.

The naive version doesn't work. If you cast/transmute to change the lifetime, it seems fine on the surface (you check for membership before returning); however, I believe a malicious key type could cause unsoundness.