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.

Brandiebrandise

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.

Portis

Thanks for taking the time to answer. I was thinking about this from a "TMTOWTDI, so which way is better" perspective, whereas the answer is really "it depends". – Brandiebrandise

FYI, ArraySegment<T> is a structure in the Framework which implements IList<T>. – Overplay

Answer 2

if Foo2 returns void, it doesn't really matter. But suppose Foo2 returned a modified version of the list. With an IList parameter, the best it could do is return another IList. But with an IList constraint, it could return any type the caller wants assuming that type implements IList

Dufour

I don't think a generic type parameter alone will determine the return type of a method. – Sniff

no, but it gives you the opportunity to do so... public static T Foo1<T>(T list) where T : IList – Dufour

@RobertLevy Good point, I was thinking about this hypothetically and hadn't considered the issue of wanting more specificity for the return type. – Brandiebrandise

Answer 3

Aside from all the lower-level implications, when the list is encapsulated and there are operations to modify it, you're talking about an object and this list shouldn't be exposed (in most cases), therefore the use of generics are pointless and expose, without a valid reason, the inner workings of the class.

If you have a data structure that needs to expose the list, then specifying it by generics tend to make the data presence easier to read (IMHO).

Devise

Answer 4

Reagrding your example I would prefer the second approach. Generic methods or classes are mostly used when the caller can use them with more than on type as in your example. In this case you can avoid a base class (e.g. object) as return value and provide type safe return values. On simple sample

public class Foo<T>
{
    public T GetSomething()
    {
        return default(T);
    }
}

Whitesell

Answer 5

Simple :

here you gave a pretty easy example : since you already gave the top interface ILIST.

but ,

lets say i have an instanc Of Objects.

JimMorrison
JohnLennon
SnowieWhite

they are all from ILegends.

they are all singers objects ( var singer = new Singer())

YokOno is also a singer but not Ilegends ( mmmm ... wonder why?)

and your function can take Singer.

but you want to make sure that only ILegeneds will be valid... so here is your answer.

Eveleen