Generic type parameter variance in the CLR

Mindless Link Propagation

.Net Security Blog — Fri, 18 Feb 2005 04:27:00 GMT

re: Generic type parameter variance in the CLR

Paul Tessier — Mon, 28 Feb 2005 17:35:00 GMT

After using generics for that last month, I know I can never go back again. Right now through, I'd kill for exactly what you have in your "theoretical extension of C#".

I've writen:
class A<T>
{
void F<T2>(A<T2> val) where T2 : T
}

I'm going crazy.

re: Generic type parameter variance in the CLR

dcoetzee — Thu, 16 Feb 2006 00:05:40 GMT

Hi Rick. Today a tester walked into my office and complained to me that he can't convert a List of derived classes to a List of the base class. When I explained that that would violate type safety because List objects are not read-only, he asked if he could just wrap it in some kind of read-only adapter which would then be covariant. He should be able to, but the sad answer is no - it would be great to have this simple kind of OO type support in C# generics. Definitely something to push for in C# 3.0.

re: Generic type parameter variance in the CLR

rmbyers — Thu, 16 Feb 2006 00:22:29 GMT

Yep, that's exactly what you'd want to be able to do. In fact, IEnumerable<T> is that "read-only wrapper". I've spoken with the C# team about this. In fact, Mads Torgersen is the key person that got this support added to Java (in the form of wildcard types), and I was impressed to see that he now works on our C# team. Not surprisingly, he'd like very much to be able to add this to C#, but there are additional complications in C# that make that very difficult (in Java, wildcard types were added at the same time as generics - in C# we've got a significant compatability problem, plus in Java generics exist only in the compiler, not in the run-time type system like in the CLR). So, unfortunately, I wouldn't hold your breath waiting for this in C# 3.0.

Covariance versus Contravariance

Michael Primeaux's Blog — Sun, 30 Apr 2006 18:39:13 GMT

Lately, I've been fielding questions as related to conversion between related generic types in C# 2.0....

More on generic variance

Rick Byers — Sun, 04 Jun 2006 02:54:36 GMT

In my entry on generic variance in the CLR, I said that you can’t convert a List&lt;String&gt; to a List&lt;Object&gt;,...

Only Talking Sense » C# Generics

Only Talking Sense » C# Generics — Mon, 19 Jun 2006 16:13:40 GMT

PingBack from http://onlytalkingsense.wordpress.com/2006/06/19/c-generics/

CoVariance, Contravariance and Generics

The Original .NET Geek — Mon, 31 Jul 2006 23:26:21 GMT

This post is aresult of an expensive lesson I learned. The situation: A MVP style architecture, Presentation

re: Generic type parameter variance in the CLR

TheInsaneCoder — Mon, 14 Aug 2006 16:29:00 GMT

If generic casting to base generic classes is not possible, is there a way we can work around this without writting hundreds of lines of code?

I've got in the simplest terms a lockmanager which manages locks on rows in a table. This lock manager is inherited by a lot of managers of specific tables and features.

A generic form of mine takes editor controls and manages all the lock/save operations. If i want to provide a "business manager" to it as much as a "department manager" it won't let me do it.

If i can't convert back to a generic lock manager to handle various types of object how can i work around that still keeping it secure and allowing only business objects or contact objects to their respective managers?

re: Generic type parameter variance in the CLR

Jeorge Lukasing — Sun, 27 Aug 2006 12:20:53 GMT

Very many thanks for a good work. Nice and useful. Like it!

re: Generic type parameter variance in the CLR

rmbyers — Wed, 30 Aug 2006 23:22:19 GMT

TheInsaneCoder,
Sorry for the delay - I've been out of the office for the past few weeks (just had my first child!).

Casting (and even implicit conversions) to base generic classes IS possible. Eg., if Bar<T> derives from Foo<T> then you can convert a Foo<int> to a Bar<int>.

What we're talking about here is converting between different generic instantiations (eg. List<Foo> to List<Bar>). In general this is not safe, and if you find yourself wanting to do this a lot it often means there is a flaw in your generic type design (eg. you don't really want the strong typing generics provide).

To mix between the strong-typing and weak-typing world, you often want to have generic classes implement non-generics interfaces. This allows you to throw away the extra type information embodied by the generic type parameters when its appropriate to do so.
Eg., List<T> implements the non-generic IList and IEnumerable interfaces for exactly this reason.

Its hard to say for sure without a more detailed description (and/or code) of what you're trying to do. But it sounds to me like you perhaps want your generic lock managers to implement a non-generic lock manager interface.

re: Generic type parameter variance in the CLR

cherridge — Thu, 07 Sep 2006 23:09:31 GMT

My real confusion (and i'm sure this is what your describing) is why this doesn't work...

I'm only casting the generic type with it's T parameter going back to an interface that T derives from...

Am i missing something here or is it just impossible in c#2?

interface IAmAString
{
string Text {get;}
}
class MyStringClass : IAmAString
{
string _Text;
public string Text
{
get
{
return (_Text);
}
}
}
class GenericClassA<T> where T : IAmAString
{

}
class Program
{
static void Main(string[] args)
{
object o = new GenericClassA<MyStringClass>();
GenericClassA<IAmAString> newo = (GenericClassA<IAmAString>)o;
//I've just thrown a casting exception
}
}

re: Generic type parameter variance in the CLR

rmbyers — Thu, 07 Sep 2006 23:49:44 GMT

Cherridge,
Yes that is exactly what I'm describing. It's intentionally not possible (if it were, you'd lose a lot of the benefits of generics).

Specifically, if you could do that, then what would a program like this do?:

interface IAmAString
{
string Text { get;}
}
class MyStringClass : IAmAString
{
string _Text;
public string Text
{
get
{
return (_Text);
}
}
}
class OtherStringClass : IAmAString
{
int _num;
public string Text
{
get
{
return _num.ToString();
}
}
}
class GenericClassA<T> where T : IAmAString
{
GenericClassA(T init)
{
_field = init;
}

public T _field;
}
class Program
{
static void Main(string[] args)
{
GenericClassA<MyStringClass> o = new GenericClassA<MyStringClass>(new MyStringClass());
GenericClassA<IAmAString> newo = (GenericClassA<IAmAString>)o;

// If that worked, I could now do this:
IAmAString newString = new OtherStringClass();
newo._field = newString;

// Now what type should this be? Generics are supposed to allow this to work without a type-check
// or possibility if InvalidCastException. But we've got a OtherStringClass stored where we expect
// to have a MyStringClass!
MyStringClass s = o._field;
}
}

Perhaps really what you want to write is something more like this (similar to how List<T> implements the non-generic IList interface):

interface IAmAString
{
string Text { get;}
}
class MyStringClass : IAmAString
{
string _Text;
public string Text
{
get
{
return (_Text);
}
}
}
interface IStringClass
{
IAmAString SomeFunc();
}

class GenericClassA<T> : IStringClass where T : IAmAString
{
public T SomeFunc()
{
...
}

// This function lets us decide explicitly what happens when a T is converted to a IAmAString.
// In this case we can just do an implicit conversion. In other scenarios you may want a runtime-checked
// cast.
IAmAString IStringClass.SomeFunc()
{
return SomeFunc();
}
}
class Program
{
static void Main(string[] args)
{
// Here we can use things knowing their exact type
GenericClassA<MyStringClass> o = new GenericClassA<MyStringClass>();
MyStringClass s1 = o.SomeFunc();

// But if we want to erase some of that type information, we still can:
IStringClass newo = o;
IAmAString s = newo.SomeFunc();
}
}

C# generics covariance

Andrew Stopford's Weblog — Thu, 28 Dec 2006 18:17:50 GMT

I've posted about this before , largely covariance is possible in C# delegates but not featured in

Chris Donnan : Programming - Brooklyn Style - Generics lack covariance/ contravariance

Sat, 03 Feb 2007 21:29:21 GMT

PingBack from http://chrisdonnan.com/blog/2007/02/03/generics-lack-covariance-contravariance/

Invari

Nuno Filipe Godinho — Thu, 14 Jun 2007 20:19:39 GMT

re: Generic type parameter variance in the CLR

cisjokey — Thu, 13 Sep 2007 12:20:17 GMT

Hello dear

I'hope i can post something usefull. I'had the same problem as you all. And (in some cases) its easy to come around;

I make a sample with a "Searcher" class;

class Searcher

{

public ICollection<ISearchItem> Search(IList<ISearchItem> listToSearch)

{ //searches through the items }

}

Now if you have a list with items of a type that implements this ISearchItem interface, you get the compiler-errors as you described above.

e.g List<SearchItem>

what you could do is the following thing;

class Searcher

{

public ICollection<T> Search<T>(IList<T> listToSearch) where T:ISearchItem

{ //searches through the items }

}

And now, you can use your Interface without writing hundreds of lines of code. You do not see which type is expected with intellisense when using this Searchmethod, but the method is at least "typesave".

If this post is useless or misplaced/misinterpreted, just delete it (im not that programming geek and do not know if this is a suiteable solution).

Greetings

Cis

re: Generic type parameter variance in the CLR

rmbyers — Thu, 13 Sep 2007 18:47:06 GMT

Cis,

Yes - that's exactly right, in some cases you can use a generic method with a base class constraint to overcome this limitation. I talked about this option in detail in my follow-up post here: http://blogs.msdn.com/rmbyers/archive/2006/06/01/613690.aspx

re: Generic type parameter variance in the CLR

richardcollins — Wed, 14 Nov 2007 15:14:07 GMT

I would certainly like to see this kind of extension made to C#, but I would prefer the syntax to be, e.g.:

interface IEnumerable<out T> { ... }

interface IComparer<in T> { ... }

as this describes the constraints more clearly.

-Richard.