Hidden KeyRef type complicates key lookup

[JayKickliter]

Because keys are stored inside a KeyRef type, .get() can be complicated or inefficient. For instance, if I have a cache which stores the key as a Vec<u8>, I'd expect to be able to lookup a value a in the cache using a &[u8], but that's not possible:

error[E0277]: the trait bound `KeyRef<Vec<u8>>: Borrow<[u8]>` is not satisfied
  --> native/lib.rs:98:17
   |
98 |     match cache.get(key.as_slice()) {
   |                 ^^^ the trait `Borrow<[u8]>` is not implemented for `KeyRef<Vec<u8>>`
   |
   = help: the following implementations were found:
             <KeyRef<K> as Borrow<K>>

[al8n]

Because keys are stored inside a KeyRef type, .get() can be complicated or inefficient. For instance, if I have a cache which stores the key as a Vec<u8>, I'd expect to be able to lookup a value a in the cache using a &[u8], but that's not possible:

error[E0277]: the trait bound `KeyRef<Vec<u8>>: Borrow<[u8]>` is not satisfied
  --> native/lib.rs:98:17
   |
98 |     match cache.get(key.as_slice()) {
   |                 ^^^ the trait `Borrow<[u8]>` is not implemented for `KeyRef<Vec<u8>>`
   |
   = help: the following implementations were found:
             <KeyRef<K> as Borrow<K>>

Thanks for pointing it out! KeyRef is used to break the Rust language limitation to avoid using Rc, I am not aware that this will bring inefficient to something key like Vec<T> situation. I will try to fix it in the next 2 or 3 weeks, if you have any good ideas, welcome PR. If you cannot wait and do not care about the no_std and the background cache algorithms, there are two modern high-performance cache crates that guarantee concurrent-safe, stretto and moka.

[stevefan1999-personal]

This is needed for rustls. @al8n would you like to take a look on how to solve it again?

[al8n]

Sorry for the late fixes. It was fixed by the new release 0.2.6.