You cannot unwrap an Arc that you don't own

You cannot unwrap an Arc that you don't own

use std::sync::{Arc, RwLock};
use std::collections::HashMap;
use std::hash::Hash;
use std::cmp::Eq;

trait SessionStore<K, V> {
    fn remove(&self, key: &K) -> bool;
}

type Store<K, V> = RwLock<HashMap<K, RwLock<V>>>;

pub struct HashSessionStore<K, V>{
    store: Arc<Store<K, V>>
}

impl<K: Clone + Send, V: Send> Clone for HashSessionStore<K, V> {
    fn clone(&self) -> HashSessionStore<K, V> {
        HashSessionStore {
            store: self.store.clone()
        }
    }
}

impl<K: Hash + Eq + Send + Sync, V: Send + Sync> HashSessionStore<K, V> {
    /// Create a new instance of the session store
    pub fn new() -> HashSessionStore<K, V> {
        HashSessionStore {
            store: Arc::new(RwLock::new(HashMap::<K, RwLock<V>>::new()))
        }
    }
}

impl<K: Hash + Eq + Send + Sync + Clone, V: Send + Sync + Clone> SessionStore<K, V> for HashSessionStore<K, V> {
    fn remove(&self, key: &K) -> bool {
        match Arc::try_unwrap(self.store) { // borrow problem here!!! how to solve this???
            Ok(v) => {
                v.write().unwrap().remove(key);
                // how to write the following????
                    // if the hashmap.remove function found the item and removed it
                        // return true
                    // if the item was not removed or the key wasn't found in the hashmap
                        // return false
            },
            Err(e) => false,
        }
        //false
    }
}

impl<K: Hash + Eq + Send + Sync + Clone, V: Send + Sync + Clone> SessionStore<K, V> for HashSessionStore<K, V> {
    fn remove(&self, key: &K) -> bool {
        self.store.write().unwrap().remove(key).is_some()
    }
}

fn main() {}

0658 BruceLee+| I'm having a little borrow problem with my remove function here:
| https://play.rust-lang.org/?gist=c3c43fc4a4362ec8c5f4705a77dd6ef2&version=nightly&backtrace=0 - how can I solve this? :)
0702 Xion | BruceLeet: Try to provide compileable playground links next time
0702 @mbrubec+| BruceLeet: Does something like this work?
0703 @mbrubec+| compileable link: http://is.gd/e2A0QG
0703 Xion | Yeah I figured out the SessionStore trait from compiler errors.
0704 Xion | BruceLeet: You cannot unwrap an Arc that you don't own.
0704 Xion | Inside remove() you only have borrowed &self.
0704 Xion | So you cannot "destroy" one of the fields of it.
0704 @mbrubec+| Fortunately you don't need to unwrap an Arc in order to call methods on its contents
0704 Xion | Indeed.
0705 BruceLee+| @mbrubeck Fantastic!! it works. Thanks so much! :-)
0706 Xion | The relevant phenomenon is called Deref coercions. Arc can "magically" behave like T where necessary.
0706 BruceLee+| And @Xion thanks for the advice as well :-) Hopefully I'll "learn" rust some day. Right now I feel so dumb, coming from high level languages haha :D
0706 Xion | Eh, it's not even high level vs. low level.
0706 Xion | Rust is a special snowflake :)
0707 ~stevekl+| yeah, it's weird to everyone for different reasons :)
0707 Xion | BruceLeet: Btw by "compileable" I meant "failing with the error you have problems with". If it was actually compileable, you probably wouldn't have to
| ask :)
0709 * | Xion should've probably pull out a Haskell and say "code that type-checks".
0711 Xion | steveklabnik: My theory is that the optimal languages to know before learning Rust are Haskell and C, in this order.
0711 ~stevekl+| i think ocaml is probably better than haskell