title: Benefits of contravariance in IComparer & IEqualityComparer interfaces
body: <p>On the <a href="http://msdn.microsoft.com/en-us/library/dd465120.aspx" rel="nofollow">msdn page</a> on contravariance I find a quite interesting example that shows "benefits of contravariance in IComparer"</p>
  
  <p>First they use a fairly odd base &amp; derived classes:</p>
  
  <pre><code>public class Person
  {
      public string FirstName { get; set; }
      public string LastName { get; set; }
  }
  
  public class Employee : Person { }
  </code></pre>
  
  <p>I can already say that its a bad example cause no class ever just inherits a base class without adding at least a little something of its own. </p>
  
  <p>Then they create a simple IEqualityComparer class</p>
  
  <pre><code>class PersonComparer : IEqualityComparer&lt;Person&gt;
  {
      public bool Equals(Person x, Person y)
      {            
          ..
      }
      public int GetHashCode(Person person)
      {
         ..
      }
  }
  </code></pre>
  
  <p>Next the example in question goes.</p>
  
  <pre><code>List&lt;Employee&gt; employees = new List&lt;Employee&gt; {
                 new Employee() {FirstName = "Michael", LastName = "Alexander"},
                 new Employee() {FirstName = "Jeff", LastName = "Price"}
              };
  
  IEnumerable&lt;Employee&gt; noduplicates = 
  employees.Distinct&lt;Employee&gt;(new PersonComparer());
  </code></pre>
  
  <p>Now my question - first of all in this case Employee is an unneeded class, its true that it can use PersonComparer for this situation because it is in fact just a person class!</p>
  
  <p>In real world however <code>Employee</code> will have at least one new field, lets say a <code>JobTitle</code>. Given that its pretty clear that when we want distint Employees we would need to take that JobTitle field in mind for comparison, and its pretty clear that Contravariant Comparer such as person comparer isn't suited for that job, cause it cannot know any new members Employee has defined. </p>
  
  <p>Now of course any language feature even a very odd one could have its uses, even if its illogical for some situation, but in this case I think it won't be useful far too often to be a default behavior. In fact it appears to me as we are breaking type safety a little bit, when a method expects a Employee comparer we can in fact put in a person or even object comparer and it will compile with no problems. While its hard to imagine our default scenario would be to treat Employee like an object..or basic Person.</p>
  
  <p>So is it really a good contravariance for default for those interfaces?</p>
  
  <p><strong>EDIT:</strong> I understand what contravariance and covariance is. I am asking why those comparing interfaces were changed to be contravariant on default.</p>