Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implications of Arc<K>: Borrow<Q> #166

Closed
tatsuya6502 opened this issue Jul 9, 2022 Discussed in #163 · 2 comments
Closed

Implications of Arc<K>: Borrow<Q> #166

tatsuya6502 opened this issue Jul 9, 2022 Discussed in #163 · 2 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@tatsuya6502
Copy link
Member

Discussed in #163

Originally posted by JayKickliter July 9, 2022
For my particular use case I'm finding moka::sync::Cache requirement of Arc<K>: Borrow<Q> very restrictive, as my keytype is somewhat expensive to create. Is this an absolute requirement for this kind of cache or an implementation detail?

Expected behavior

Using HashMap as an example, I'd expect to be able to querey using a &[u8] when the key type is Vec<u8>.

    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());
error[E0277]: the trait bound `Arc<Vec<u8>>: Borrow<[u8]>` is not satisfied
   --> src/main.rs:5:11
    |
5   |     cache.contains_key([1_u8].as_slice());
    |           ^^^^^^^^^^^^ the trait `Borrow<[u8]>` is not implemented for `Arc<Vec<u8>>`
    |
    = help: the trait `Borrow<T>` is implemented for `Arc<T>`
note: required by a bound in `moka::sync::Cache::<K, V, S>::contains_key`
   --> /Users/jay/.cargo/registry/src/github.com-1ecc6299db9ec823/moka-0.9.0/src/sync/cache.rs:880:17
    |
880 |         Arc<K>: Borrow<Q>,
    |                 ^^^^^^^^^ required by this bound in `moka::sync::Cache::<K, V, S>::contains_key`

EDIT: I now wonder if this could be considered a bug after noticing the following.

This also seems to imply that the docs contains_key are incorrect:

The key may be any borrowed form of the cache’s key type,

@tatsuya6502 tatsuya6502 added the bug Something isn't working label Jul 9, 2022
@tatsuya6502 tatsuya6502 self-assigned this Jul 12, 2022
@tatsuya6502 tatsuya6502 added this to the v0.9.1 milestone Jul 12, 2022
@tatsuya6502
Copy link
Member Author

I found a solution for sync and future caches. I am working on it here:

If it goes well, I will publish Moka v0.9.1 with the solution.

@tatsuya6502
Copy link
Member Author

I am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant