Should generic constraints be preferred to using interfaces as parameter types?

Question

Consider this trivial function:

public static bool IsPositive(IComparable<int> value)
{
    return value.CompareTo(0) > 0;
}

Now, if I pass an int to this method, it gets boxed. Wouldn't it therefore be better to define the above method as follows?

public static bool IsPositive<T>(T value) where T : IComparable<int>
{
    return value.CompareTo(0) > 0;
}

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 IsPositive<int> accepts a parameter of type int).

The example code above is clearly quite pointless. But my broader question is: wouldn't it always 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?

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 IEnumerable<T>." But I'm wondering if there's a greater difference between these approaches that is escaping me at the moment.

Answer 1

One issue would be with the fact that the generic constrain isn't really part of the signature. If you have ...

static T Method<T>(T value) where T : ICompareable<int>

... and ...

static T Method<T>(T value) where T : IEnumerable<int>

... the compiler wouldn't have a way to know which is which.

And to invoke Eric Lippert...

• Constraints are not part of the signature

• A Generic Constraint Question

Answer 2

Another issue would be when the generic constraint is on a parameterized type's generic type parameters, such as

static bool AreAllTheSame<T>(IEnumerable<T> something)
  where T : IEquatable<T>

It is not always possible to convert the generic type parameter this way, unless you introduce a second type parameter like this:

static bool AreAllTheSame<S, T>(S something)
  where S : IEnumerable<T>
  where T : IEquatable<T>

That just doesn't look right.

Answer 3

There was some confusion in the comments to the question regarding whether or not the call to the method induces a boxing after the argument is passed.

When you make a call to a virtual method on an expression whose type is a type parameter with a constraint on it, the C# compiler emits a constrained.callvirt instruction. As one would hope, this does the right thing; the boxing only happens when absolutely necessary.

For details regarding the precise boxing semantics of constrained virtual calls, read the documentation:

http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.constrained.aspx