title: Should generic constraints be preferred to using interfaces as parameter types?
body: <p>Consider this trivial function:</p>
  
  <pre><code>public static bool IsPositive(IComparable&lt;int&gt; value)
  {
      return value.CompareTo(0) &gt; 0;
  }
  </code></pre>
  
  <p>Now, if I pass an <code>int</code> to this method, it gets boxed. Wouldn't it therefore be better to define the above method as follows?</p>
  
  <pre><code>public static bool IsPositive&lt;T&gt;(T value) where T : IComparable&lt;int&gt;
  {
      return value.CompareTo(0) &gt; 0;
  }
  </code></pre>
  
  <p>Using a generic constraint in this way, I can achieve exactly the same functionality as the code above, with the added benefit that no boxing is necessary (since a call to <code>IsPositive&lt;int&gt;</code> accepts a parameter of type <code>int</code>).</p>
  
  <p>The example code above is clearly quite pointless. But my broader question is: <strong>wouldn't it <em>always</em> make sense to define methods in the latter way (using a generic constraint rather than having a parameter of some interface type), to avoid the potential boxing of value types?</strong></p>
  
  <p>I suspect that the answer is likely to be "yes, but it requires more typing and in many cases encountering a value type will be very unlikely, such as when a method accepts some <code>IEnumerable&lt;T&gt;</code>." But I'm wondering if there's a greater difference between these approaches that is escaping me at the moment.</p>