Should `Handle<T>` implement `DerefMut<T> where T: LocalHandle`?

[peterhuene]

I can envision uses cases where there are "setter" functions on a resource:

resource person {
   get_name: function() -> string
   set_name: function(name: string)
}

new_person: function(name: string) -> person

Right now the implementer of this interface can't get a mutable reference to the underlying T as Handle<T> doesn't implement DerefMut.

Thoughts on implementing it and its safety guarantee (should we wrap the underlying resource with a RefCell to at least get runtime borrow-checking)?

[peterhuene]

I mean, it's always an option to foist RefCell into the user's resource type itself, it just makes for a more cumbersome implementation for users that want mutable state.

Personally I think I'd prefer Handle to implement DerefMut (where T impls LocalHandle) so that things are just easier for users.

[alexcrichton]

Yeah currently the "intended way" is to use RefCell in your type itself. It is not the intention, however, that that's awful to use!

wasm-bindgen bakes in the RefCell for you automaticaly and I think that ended up working out really well (most everyone just forgets about mutability issues and are caught when things go wrong by accident). That being said though the design of interface types is different. As-specified right now when you get a handle in parameter you get an owned handle value which has to be deallocated at some point, which is unlike wasm-bindgen where you're taking references and mutable references so the shim function can call the borrow_mut and have the RefMut to destroy.

Basically I don't know how to enable this right now. I don't know where the RefMut would safely live and how that'd get tied to enable DerefMut.

I haven't really put too much effort into thinking about handles yet, so I'm sure there's something that can be done to improve the situation!