Using `&str` to fetch a value with a `String` key about lru-rs

[rohitjoshi]

@jeromefroe I have similar issue where Key is Vec<u8> but required to access using &[u8]. With the nightly flag, it works fine but I would like to use Rust stable release in production. This is the only functionality (to avoid memory allocation) which requires nightly feature. Any way to solve without using nightly release?

[jeromefroe]

Hey @pimeys! Do you have a reproducible example by chance? I made a simple example and was able to call the get method on a LruCache<String, T> with a &str key, so I think something else may be going on. My example is:

extern crate lru;

use lru::LruCache;
use std::string::String;

fn main() {
  let mut cache: LruCache<String, i32> = LruCache::new(2);

  cache.put("apple".to_owned(), 1);

  let key: String = "apple".to_owned();
  assert_eq!(*cache.get(&key).unwrap(), 1);
}

[pimeys]

What I want to do here is to skip the extra allocation when fetching from cache, and this doesn't work:

use lru::LruCache;

fn main() {
    let mut cache: LruCache<String, i32> = LruCache::new(2);
    
    cache.put("apple".to_owned(), 1);
    assert_eq!(cache.get("apple"), Some(1));
}

And in our case what we do is we check first is the item in the cache (first allocation for the fetch), then log if we hit the cache, or if not store to the Lru (second allocation for storage) and then again fetch from the cache.

I'd be much happier if we could use &str to fetch a key from a cache holding String as its key. They both are Eq and Hash, so it should be possible, as it is in std:collections::HashMap.

Or I change our interfaces to take &String instead of &str, but that would break all the interfaces only for caching, which also doesn't feel right.

[jeromefroe]

Hey, sorry, you're right, this doesn't work by default. You'll have to enable the nightly feature to do this. The change to support this was originally added in #40 but I noticed that it didn't keep up to date with some of the changes in the nightly compiler so I addressed those issues in #86 and then released v0.5.2.. To get this to work, therefore, your Cargo.toml should contain the following:

[dependencies.lru]
version = "0.5.2"
features = ["nightly"]

Let me know if that fixes things.

[pickfire]

version 0.6.6 and still seemed to have this issue