Hide Guard where possible
jonhoo opened this issue · comments
We should provide methods that wrap get, insert, remove, and friends so that the user does not need to know about Guard. I'm not sure what the best way to do so is, but it's worth thinking about.
The topic here is to chose what is the default behavior maybe?
We could chose to let get, insert, remove, etc to be default guarded and implement a get_with_guard, insert_with_guard, etc (or any other naming we may decide) so we are explicit on it.
Or the other way around, let the methods use the guard parameters and create new ones as for example get_guarded where they use a default inner guard inside.
What does make more sense here?. both seem logical for me.
So, I think the tricky part here is how we even write a get method that does not take a guard. We need to return a reference into the map, but that reference has to be guarded by a Guard, otherwise it can be invalidated at any time. I think what we will need is a signature like
fn get(&self, key: K) -> ReadGuard<'_, K, V>where ReadGuard: Deref<V> and contains a guard created inside of get. There will have to be some unsafe there too I believe, since we will have to move the Guard into the struct (and move it to return it from the function), which in turn will break the lifetime of the Shared that we return from get_node. It should be safe, since we never actually drop the Guard that protects the Shared, but it will require some unsafe lifetime juggling (and same for insert and remove).
Looks like this will be solved by #45
Closed by #45.