title: Using Rust dereferencing operators &* vs * with Self?
body: <p>I want to write an LRU Cache with a memory size limitation rather than the "number of objects" limitation in std.  After trying to figure it out for myself, I cheated and looked at <a href="https://github.com/thestinger/rust-core/blob/master/core/lru.rs" rel="nofollow noreferrer">an existing implementation</a>, and I <em>almost</em> understand it, but this stops me:</p>
  
  <pre><code>struct KeyRef&lt;K&gt; {
      k: *const K,
  }
  
  impl&lt;K: Hash&gt; Hash for LruKeyRef&lt;K&gt; {
      fn hash&lt;H: Hasher&gt;(&amp;self, state: &amp;mut H) {
          unsafe { (*self.k).hash(state) }
      }
  }
  
  impl&lt;K: PartialEq&gt; PartialEq for LruKeyRef&lt;K&gt; {
      fn eq(&amp;self, other: &amp;LruKeyRef&lt;K&gt;) -&gt; bool {
          unsafe { (*self.k).eq(&amp;*other.k) }
      }
  }
  </code></pre>
  
  <p>It's that last <code>unsafe</code> line that I don't understand.  I'm using a <code>HashMap</code> as the underlying structure, the key is stored with the value, and I want the hasher to be able to find it. I make the working hash key a reference to the real key and provide <code>Hash</code> and <code>PartialEq</code> functions such that the <code>HashMap</code> can find and use the key for bucketing purposes.  That's easy.</p>
  
  <p>I understand then that I have to compare the two for <code>PartialEq</code>, and so it makes sense to me that I have to use <code>*self.k</code> to dereference the current object, so why <code>&amp;*other.k</code> for the <em>other</em> object?  That's what I don't understand.  Why isn't it just <code>*other.k</code>?  Aren't I just dereferencing both so I can compare the actual keys?</p>