Recently I found a very surprising behavior in c#.
I had a method which takes IEnumerable<Object>
as a parameter and i was passing
IEnumerable<string>
but it's not possible.
While in c# everything can be upcast to Object than why this is not possible?
It's totally confusing for me.
Please someone clear me on this issue.

- 3,900
- 1
- 18
- 20

- 16,125
- 37
- 97
- 135
-
How is it not possible? Is it throwing an ArgumentException? Besides, what's the point of using a generic IEnumerable if you're going to declare it as an Object? – Jon Limjap Mar 04 '09 at 07:52
-
Same as: http://stackoverflow.com/questions/6557/in-c-why-cant-a-liststring-object-be-stored-in-a-listobject-variable – Daniel Earwicker Mar 04 '09 at 07:59
5 Answers
The technical term for this is that generics are invariant in C# 3.0 and earlier. From C#4.0 onward, the cast works.
What invariant means is that there is no relationship between two generic types just because their generic type parameters are related (i.e. are sub- or supertypes of each other).
In your example, there is no typing relationship between an IEnumerable<object>
and an IEnumerable<string>
, just because string is a subtype of object. They're just considered two completely unrelated types, like a string and an int (they still both are subtypes of object, but everything is)
There are a few workarounds and exceptions for this issue you've run into.
First, you can cast each string individually to object, if you're using .NET 3.0 you can do that using the Cast<T>()
extension method. Otherwise, you can use a foreach and put the result into a new variable of the static type you want.
Second, arrays are an exception for reference type, i.e. passing in a string[] type to a method acccepting object[] types should work.

- 8,880
- 1
- 30
- 48
-
1Just to update this older answer, covariance and contravariance are now supported in C#, and this is now a valid cast. – Paul Tyng Nov 03 '11 at 14:31
As others have pointed out, generics types are invariant. IEnumerable<T>
could be co-variant but C# doesn't currently support specifying variants. C# 4.0 is expected to support variants so this might be supported in the future.
To work around this now you can using a the LINQ extension method Cast<object>()
. Assuming you have a method called Foo
that takes an IEnumerable<object>>
. You can call it like this,
Foo(stringEnumerable.Cast<object>());

- 27,773
- 7
- 53
- 49
The easiest way to pass IEnumerable<string>
to function requiring IEnumerable<object>
is through converting function like this:
public IEnumerable<object> convert<T>(IEnumerable<T> enumerable)
{
foreach (T o in enumerable)
yield return o;
}
When C# 4 comes out, this won't be neccessary, because it will support covariance and contravariance.

- 97,721
- 20
- 209
- 280

- 9,461
- 6
- 55
- 66
You should be using
IEnumerable<T>
if you want to pass in different types, then you can query T to find out what type it is.

- 45,739
- 9
- 81
- 112
A good way to think about this is to ask yourself "What would happen if you could do this?". Take the following example:
IEnumerable<String> strings=...;
IEnumerable<Object> objects = strings; // assume this were legal
objects.Add(new Integer(5)); // what the...
We just added an integer to a list of strings. The compiler does this to preserve type safety.

- 131,367
- 29
- 160
- 239
-
IEnumerable
doesn't have an Add method though... And in C# 4.0 you will actually be able to perform this cast as the declaration will change to IEnumerable – Greg Beech Mar 04 '09 at 08:07allowing it to be (safely) contravariant. -
Well substitute any generic class that does have an Add method like List then – 1800 INFORMATION Mar 05 '09 at 07:07
-
-1: `IEnumerable
` becomes `IEnumerable – Sam Harwell Mar 23 '10 at 22:56` in .NET 4 specifically because your argument makes sense for a container but *not* for an enumeration.