Difference between interface as type constraint and interface as parameter?

Question

If I wanted to create a method that takes an instance of IList as a parameter (or any other interface, but let's use IList as an example), I could create a generic method with a type constraint, e.g.:

public static void Foo1<T>(T list) where T : IList
{

}

Alternatively, I could create a method that takes an IList parameter directly:

public static void Foo2(IList list)
{

}

For all intents and purposes, it seems like these methods behave exactly the same:

List<string> myList = new List<string>();
Foo1(myList);
Foo2(myList);

So here's my question -- what's the difference between these two approaches? It seems like the second approach is slightly more readable; are there any other differences I should be aware of (different IL being generated, etc)? Thanks in advance.

Answer 1

A couple of differences:

• If you ever need the real type again (e.g. to pass to another generic method or for logging) then the generic method will be better
• T could be a value type and still end up being unboxed in the generic form. It's pretty unlikely that this would be the case for IList, but for other interfaces it's highly plausible
• The generic form allows you to specify a concrete implementation type which is different from the actual object type. For example, you might pass in a null reference but still want to know which implementation type T is
• They will be JITted differently; see Joe Duffy's recent blog post on generics for more information

It really depends on what you're doing of course... unless you actually need to know anything about T within the method, the only benefit to the generic form is the boxing point.