Implications of Arc<K>: Borrow<Q>
#163
-
For my particular use case I'm finding Expected behaviorUsing use std::collections::HashMap;
let mut map: HashMap<Vec<u8>, ()> = HashMap::new();
map.insert(vec![1_u8], ());
map.contains_key([1_u8].as_slice()); Failing example, simplified use moka::sync::Cache;
let cache: Cache<Vec<u8>, ()> = Cache::new(1);
cache.insert(vec![1_u8], ());
cache.contains_key([1_u8].as_slice());
EDIT: I now wonder if this could be considered a bug after noticing the following. This also seems to imply that the docs
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
@JayKickliter — Thank you for reporting. I have converted this into a GitHub issue #166 and let me try to fix it.
I would say it is an implementation detail. Moka cache wraps I tried briefly and could not fix. But there has got to be a way. |
Beta Was this translation helpful? Give feedback.
-
Me too, but the code base is much more expansive than I realized and I got lost. |
Beta Was this translation helpful? Give feedback.
@JayKickliter — Thank you for reporting. I have converted this into a GitHub issue #166 and let me try to fix it.
I would say it is an implementation detail.
Moka cache wraps
K
byArc
when storingK
to the internal storage, and the trait boundArc<K>: Borrow<Q>
does not work whenK
isVec<u8>
andQ
is&[u8]
. (Of course, it works whenQ
is&Vec<u8>
). The same thing happens whenK
isString
andQ
is&str
.I tried briefly and could not fix. But there has got to be a way.