title: When is it appropriate to require only PartialEq and not Eq?
body: <p>I am reading <a href="https://doc.rust-lang.org/book/appendix-03-derivable-traits.html" rel="noreferrer">the Rust book</a> and trying to understand use cases for <code>PartialEq</code> and <code>Eq</code> traits. </p>
  
  <p>I realise that <code>PartialEq</code> is for relations which are not necessarily reflexive (i.e. there can be such <code>x</code> that <code>x != x</code>) and that <code>Eq</code> is a marker trait which says that relation is also reflexive (and now it is a proper equivalence relation).</p>
  
  <p>The books gives an example where <code>PartialEq</code> is not enough and <code>Eq</code> is required: <code>HashMap&lt;K, V&gt;</code> lookups. Indeed, if we use as a key a data type which only implements <code>PartialEq</code> (for example floating point number), we would get in trouble when we try to use <code>NaN</code> as a key, since we won't be able to find it.</p>
  
  <p>Now, I am trying to understand what feature of a lookup makes it require <code>Eq</code>. I may be able to understand it better if I find an example of code which does not require <code>Eq</code>. </p>
  
  <p>The book says that <code>assert_eq!</code> requires only <code>PartialEq</code> so that we are able to compare things for equality. But if we write <code>assert_eq!(f64::NAN, some_code_producing_nan());</code> in a test, the test will always fail. We have the same basic issue as with using a <code>PartialEq</code> key in a <code>HashMap</code>, but for some reason it is considered appropriate here.</p>
  
  <p>What is an example of a reasonable function which requires only <code>PartialEq</code>  and adding <code>Eq</code> is not desirable/does not make sense?</p>
  
  <p>If there are no such use cases, then why do we care about splitting it into two traits <code>PartialEq</code> / <code>Eq</code>? Haskell, for example, just has <code>Eq</code>.</p>