LINQ Farm: Covariance and Contravariance in C# 4.0

DotNetKicks.com — Tue, 28 Oct 2008 21:06:16 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Josh Berke — Wed, 29 Oct 2008 17:57:30 GMT

Couple of questions for you:

Can a type param be both in and out so would the following be allowed:

public interface ICopier<in out T>

{

T Copy(t item);

}

Also can you explain why the need for the extra keywords? I can't imagine why but I am sure there is a reason.

thanks

Josh

re: LINQ Farm: Covariance and Contravariance in C# 4.0

iCe — Wed, 29 Oct 2008 22:23:10 GMT

I'm with Josh, please explain us why we need those in-out keywords. I can't figure out why is needed to do something that is what you expect, specially when talking about covariance

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Daedius — Thu, 30 Oct 2008 00:17:08 GMT

I think I understand the background. This is a feature created to support F# functional programming types. Immutable functions without side effects is a HUGE thing in functional programming. The contravariant delegates are a way of representing these functions in C#.

Basically, delegates with "in" parameters are delegates that can produce no side effects. "out" delegates are the more common garden variety delegates we all know and love.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

iCe — Thu, 30 Oct 2008 01:10:53 GMT

Daedius, in this example the "out" keyword is not a "common delegate". Indeed, it is making something that actually cannot be done "covariance".

delegate T Func1<out T>();

delegate void Action1<in T>(T a);

static void Main(string[] args)

{

// Covariance

Func1<Cat> cat = () => new Cat();

Func1<Animal> animal = cat;

// Contravariance

Action1<Animal> act1 = (ani) => { Console.WriteLine(ani); };

Action1<Cat> cat1 = act1;

}

What I´m really want to know, is why the compiler cannot do this automatically, simply by allowing you do covariance and contravariance without any keyword at all. I think if it was possible actually in some parts of the language why not in generics and delegates? As Charlie has said "In Visual Studio 2010 delegates will behave as expected", so if it's something we expect, why we are forced to use a special keyword to get expected behavior?

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Halo_Four — Thu, 30 Oct 2008 07:22:30 GMT

It is a limitation in the name of type safety. You are declaring that the interface or delegate can accept base or derived classes of the generic parameter by explicitly defining that said interface or delegate will either only allow T as input, or only allow T as output. The interface or delegate cannot be both.

If you are using covariance it means that the interface or delegate can output a value that is a class of the specified type parameter or derived from that class. If you pass a Func<Cat> to a method that expects a Func<Animal> it works fine since it will return a Cat, which is derived from Animal. That method can then treat the Cat as if it were an Animal without any ill effects.

If you are using contravariance it means that the interface or delegate will receive input of a value that is a class of the specified type parameter or derived from that class. If you pass an Action<Animal> to a method that expects an Action<Cat> it works fine as it will pass a Cat which is derived from Animal. The body of the called delegate can treat the Cat as if it were an Animal without any ill effects.

These roles are pretty specific and cannot be reversed. A method that takes a Func<Cat> cannot accept a Func<Animal> because the Animal that it returns might not be a valid Cat and it would fail. Similarly a method that takes an Action<Cat> cannot accept an Action<Animal> for the same reason. The new keywords really only apply to the implementers of fairly fundamental structures, such as IEnumerable<out T> or Action<in T>. Their benefit comes offering the flexibility in the consumption of types that consume those structures. You might never use those keywords, but because of them you can now do this:

// Illegal in C# 3.0

IEnumerable<Animal> animals = new List<Cat>();

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Bruce Pierson — Thu, 30 Oct 2008 08:56:42 GMT

"IEnumerable<Animal> animals = new List<Cat>();"

This is HUGE. I can't believe how many special interfaces I have to use to get true "programming to an interface" right now just because of this limitation.

For example, right now I have to do this:

Domain object, with CRUD or Mapper ops (much easier to code to a concrete or abstract class collection than to an interface that has no CRUD methods):

public IList<RuleState> ChildStates

{

get { return m_ChildStates; }

}

then in the interface for my runtime configurator (on the same class), I have to do this:

IList<IRuntimeRuleState> IRuntimeConfig.GetRuleStates()

{

List<IRuntimeRuleState> list = new List<IRuntimeRuleState>();

foreach(IRuntimeRuleState rs in m_ChildStates)

list.Add(rs);

return list;

}

In c# 4, I could just do:

IList<IRuntimeRuleState> IRuntimeConfig.GetRuleStates()

{

return m_ChildStates;

}

Much easier to code, not to mention far more efficient.

Can't wait.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Bruce Pierson — Thu, 30 Oct 2008 09:08:39 GMT

Your comment about this "acting as the programmer expects" is exactly right. I was very excited about generics, but my excitement was tempered when I found out I couldn't do:

...

private List<SomeObject> m_Field;

public IList<ISomeObject> Prop

{

get { return m_Field; }

}

...

As I posted previously, this covariance fix will alleviate this problem, and make us all better programmers by giving us the tools to be better programmers.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

int19h — Thu, 30 Oct 2008 11:49:08 GMT

Unfortunately, it won't alleviate your problem specifically, because IList<T> cannot be covariant. The reason is that it uses T both in arguments of methods - such as "void IList<T>.Add(T)"; and in return values - such as "T IList<T>.this[int]". This means that you won't be able to write this in C# 4.0:

interface IFoo { ... }

class Foo : IFoo { ... }

IList<IFoo> list = new List<Foo>();

In fact, at a quick glance, there are only a few basic types in the FCL that would be covered by new variance declarations: Predicate<T>, Comparer<T>, Action<...> and Func<...>, IEnumerable, IEquatable, IComparable. ICollection<T> and anything further down the inheritance chain will have to remain invariant.

As a result, I doubt that we'll see "in" and "out" in application code in class declarations often (if at all). On the other hand, it will probably become good style to always use them when declaring delegate types.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Luis Abreu — Thu, 30 Oct 2008 12:15:38 GMT

I'm with int19h on this one. Since you cannot have both in and out applied to the parameter, it seems like you won't be able to use covariance/contravariance with the most interesting collections...

btw, should I assume that we won't be getting Design By Contract on C# 4.0? Why isn't this part of tha language?It's one of those things that should have been there for a long time!

C# 4.0: Covariance and Contravariance on generics…sort of…

LA.NET [EN] — Thu, 30 Oct 2008 12:44:31 GMT

One of the things that we’ll have in C# 4.0 is covariance/contravariace working on generics…I mean, sort

re: LINQ Farm: Covariance and Contravariance in C# 4.0

OOP Sceptic — Thu, 30 Oct 2008 13:10:02 GMT

Really guys, this is so far away from what programming really means, ie working with real people to find out what they want and then implementing it that it's a total waste of time.

Has anyone here actually done a programming for a living (and I don't count writing programming books or similar wanky stuff as programming)

C# 4.0: Covariance and Contravariance on generics…sort of…

ASPInsiders — Thu, 30 Oct 2008 13:45:44 GMT

One of the things that we’ll have in C# 4.0 is covariance/contravariace working on generics…I mean, sort

re: LINQ Farm: Covariance and Contravariance in C# 4.0

iCe — Thu, 30 Oct 2008 20:05:14 GMT

Thanks Halo_Four, you have cleared a lot of things.

So the problem here is with classes that output and input the same generic parameter, so that is why it cannot be done without the "in" and "out" keywords. Also note that as Bruce Pierson and int19h commented, unfortunately this will not cover all the expected cases, like those when the parameter is used both in and out.

OOP Sceptic I´m in a real world project right know and those discussions allow me to understand better the tool that I´m using every day. And my better understanding of the tool means better products for the client, and better support.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Bruce Pierson — Thu, 30 Oct 2008 20:36:28 GMT

Thanks, int19h, for the clarification, even though it's depressing...

@OOP Sceptic

I currently have many customers using my software to actually run their manufacturing businesses (boats, trailers, clothing, and more), and it suffers from being difficult to modify to suit their needs because of the lack of flexible design patterns, and old-style procedural programming. I'm currently re-writing it using expert design pattern guidance, and I cannot believe the difference it makes to my sanity when I take the time to understand and apply these principles.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Morten Mertner — Thu, 30 Oct 2008 22:04:46 GMT

This is indeed very promising and will be helpful in many scenarios, but I'm dissapointed to see that it doesn't solve the problems with ICollection and IList.

Would it not be possible to define a new set of collection interfaces without this problem?

Or alternatively, add a mechanism that allows specifying the variance at the method level instead of at type level, so that when a generic type parameter is used for both in and out the specific use (for a method) can be explicitly specified.

It may be necessary or desired to also specify the variance on consumption, similar to how ref/out must be specified both at declaration and on invocation.

Mind you, I don't usually think about these things and Eric clearly lives in another dimension.. :)

That said, surely there must be some way to allow people to write "IList<IFoo> list = new List<Foo>();" as this is such a common pattern. I'll take compiler magic like for "int? i = null" over any "will not compile" error.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Richard — Thu, 30 Oct 2008 23:03:17 GMT

You can't allow "IList<IFoo> list = new List<Foo>();", otherwise you could end up with:

class Foo : IFoo {}

class Bar : IFoo {}

IList<IFoo> list = new List<Foo>();

list.Add(new Bar());

The only option would be to split the interface declaration into four parts - non-generic (Clear, Count, IsReadOnly, RemoveAt), covariant (GetEnumerator, indexer), contravariant (Add, Contains, IndexOf, Insert, Remove) and invariant (CopyTo).

Note that CopyTo would have to be invariant because it accepts an array of type T. You can only pass an array of U to a method which expects an array of type T if U is derived from or equal to T, but you can only put an object of type T in an array of type U if T is derived from or equal to U. Therefore, the only type U which satisfies both conditions is the type T, and the method must be invariant.

I think that this also explains why the compiler can't automatically infer the "variance-ness" of a type parameter.

Example:

static void Fill(IFoo[] values)

{

values[0] = new Foo();

values[1] = new Bar();

}

Fill(new object[2]); // Compiler error

Fill(new Foo[2]); // ArrayTypeMismatchException

Fill(new Bar[2]); // ArrayTypeMismatchException

Fill(new IFoo[2]); // Works

And if you can follow that gibberish, you've probably had too much coffee! ;)

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Richard — Thu, 30 Oct 2008 23:16:49 GMT

Sorry - I obviously meant to say that the indexer get would be covariant, while the indexer set would be contravariant.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Thomas Krause — Fri, 31 Oct 2008 00:03:41 GMT

Nice to finally see this in the language, but the choice of keywords is just horrible:

1.) we already have the out keyword for parameters, but with completly different semantics. And generic type "parameters" are similar enough to function parameters to confuse many people, especially if they are new to the language.

2.) without looking I cannot tell which one of the keywords is used for contravariance and which is used for covariance. "In" and "out" is not vocabulary I'd normally use when talking about type hierachy relations.

3.) there are far better alternatives. Why not simply use "super" and "sub" instead. It is far easier to remember that "sub T" means you can use subtypes of T and "super T" means you can use supertypes of T.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

int19h — Fri, 31 Oct 2008 10:24:53 GMT

Actually, "in" and "out" are fairly obvious because they clearly outline the restrictions on the usage of a type parameter. An "in" type parameter can only be used for values that are inputs of methods - that is, non-out/ref arguments. An "out" type parameter can only be used for values that are outputs of methods - return values, and out-arguments

> Would it not be possible to define a new set of collection interfaces without this problem?

It is possible if you basically split each collection interface into three parts: covariant, contravariant, and both. E.g. for a list:

interface IListVariant

{

int Count { get; }

bool IsReadOnly { get; }

void Clear();

void RemoveAt(int);

}

interface IListCovariant<out T>

{

T Item[int] { get; set; }

IEnumerator<T> GetEnumerator();

}

interface IListContravariant<in T>

{

void Add(T);

bool Contains(T);

void CopyTo(T[], int);

int IndexOf(T);

void Insert(int, T);

bool Remove(T);

}

interface IList<T> : IListVariant<T>, IListCovariant<T>, IListContravariant<T>

{

}

And so on for all other collection types (and all other interfaces that could also be so split). So far I haven't seen any indication that this is going to happen in .NET 4.0 (at least it's not mentioned on the "what's new in 4.0" poster), and, looking at the code above, I think it is understandable :)

> Or alternatively, add a mechanism that allows specifying the variance at the method level instead of at type level, so that when a generic type parameter is used for both in and out the specific use (for a method) can be explicitly specified.

I will repeat what I said elsewhere, and just say that the proper way to enable full variance is to do what Java guys did, and use variance markers at use-site, not at declaration-site, same as Java does it. For example, here are two methods that use IList<T> differently:

// Method can take IList<T> where T is string or any base class of string

void AddString(IList<in string> list, string s)

{

// cannot use any methods of list that return values of type T here, only those who take arguments of type T

list.Add(s);

//list[0]; // illegal here!

}

// Method can take IList<T> where T is object or any class derived from object

object GetFirst(IList<out object> list, int i)

{

// cannot use any methods of list that take arguments of type T here, only those that return values of type T

return list[i];

//list.Add(s); // illegal here!

}

re: LINQ Farm: Covariance and Contravariance in C# 4.0

OOP Sceptic — Fri, 31 Oct 2008 12:21:29 GMT

@ iCe and Bruce Pierson

Thanks for responding. I too have many hundreds of people running their finance businesses on my software.

I appreciate that advances in any particular technology are going to improve that technology, BUT it seems to me that all these somewhat esoteric terminologies are just solutions waiting for problems.

Maybe this new stuff will help you, but it's a little late in the day for magic solutions - surely these wacko extension merely highlight the flaws in OOP any way!

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Richard — Fri, 31 Oct 2008 14:58:22 GMT

@ int19h:

CopyTo can't be contravariant, as I tried to explain above. Passing an array is equivalent to passing a ref parameter. Although the method shouldn't read from the array, there's nothing in the declaration to prevent it.

Although it would be nice if "out" parameters could be used in contravariant interfaces, I don't think the CLR would support it. As I understand it, the only difference between "out" and "ref" parameters is the C# compiler's definite assignment checks.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

leblanc meneses — Tue, 04 Nov 2008 00:40:59 GMT

>As I say, contravariance is a bit confusing.

maybe the names are weird but usage is just polymorphism (some interface is expected).

I can already see this is going get missused. instead of using a factory pattern for Covariance

and aggregation to implement Contravariance. (pass you concrete object implementing an interface into another object that will make it work)

i wish there was some real world usage in these examples..

Community Convergence XLVII

Charlie Calvert's Community Blog — Tue, 04 Nov 2008 04:37:47 GMT

Welcome to the 47th Community Convergence. We had a very successful trip to PDC this year. In this post

re: LINQ Farm: Covariance and Contravariance in C# 4.0

int19h — Tue, 04 Nov 2008 22:15:06 GMT

> instead of using a factory pattern for Covariance and aggregation to implement Contravariance. (pass you concrete object implementing an interface into another object that will make it work)

Since covariance and contravariance in C# 4.0 will work only on interfaces (and delegates, which are semantically really just one-method interfaces), I don't see your point.

In fact, I don't understand it at all. How would aggregation help deal with the present problem that IEnumerable<Derived> cannot be treated as (i.e. cast to) IEnumerable<Base>, even though it is clearly typesafe and meaningful to do so?

re: LINQ Farm: Covariance and Contravariance in C# 4.0

Josh Berke — Thu, 06 Nov 2008 00:38:02 GMT

@OOP: I think learning about aditions to the language is a great way for us to learn new ways to applys technology solutions through code to our business problems. While I was very skeptical of Linq at first, I have come to enjoy Linq to Objects, as a quick way to filter and sort my collections (Especially when binding to grids).

@Everyone Else: I still don't get the need for the new key words, and I'm afraid unless I sat down with an expert who could pound it into my head with a base ball bat I won't get it. Since I'm the sole developer at my company, guess I'll have to finally go and attend a community event.

Thanks

Thoughts on C# 4.0 and .NET 4.0

James Newton-King — Sun, 09 Nov 2008 03:59:50 GMT

C# 4.0 Dynamic Lookup I really like the way the C# team tackled bring dynamic programming to the language

re: LINQ Farm: Covariance and Contravariance in C# 4.0

leblanc meneses — Mon, 10 Nov 2008 22:03:05 GMT

> IEnumerable<Derived> cannot be treated as (i.e. cast to) IEnumerable<Base>, even though it is clearly typesafe and meaningful to do so?

just so all can see what you mean, here is the test:

class Test

{

public Test()

{

List<Base> items = new List<Base>(this.GetItems());

}

public IEnumerable<Derived> GetItems()

{

yield return new Derived();

}

public class Base

{

}

public class Derived : Base

{

}

it fails to compile.

I agree semantically it 'could' compile.

On purpose during the Symantic Analysis stage the compiler won't let it compile.

Why?

You should be returning:

public IEnumerable<Base> GetItems()

{

yield return new Derived();

}

so you never couple higher layers with concrete types.

not IEnumerable<Derived> which is not meaningful since the Test class only needs the Base interface.

again i wish there was some real world examples on why this is actually needed.

Co\Contra-Variance in C# 4.0

Andrew Stopford's Weblog — Wed, 12 Nov 2008 02:22:30 GMT

Running behind on everything again, picked up a nasty stomach bug that laid me out for a few days (not

C# 4.0 New Features

Guy kolbis — Wed, 12 Nov 2008 17:01:19 GMT

There are a few new features coming out in C# 4.0. I gathered some posts that will help you to "get

re: LINQ Farm: Covariance and Contravariance in C# 4.0

tytusse — Thu, 18 Dec 2008 23:26:11 GMT

As someone pointed much earlier (so I am not 1st) - the keywords are necessary - you cant now - at runtime - what is the actual generic type of generic collection, and furthermore - using "generic" cast you will loose type information which is necessary for compile time checks and leads to stupid runtime fails, of which I dreamed to forget when I first saw generics...

public class Base

{

}

public class Derived : Base

{

}

public class Tests {

public static void Test1() {

List<Derived> derivedList = new List<Derived>();

List<Base> baseList = derivedList; // sounds fair?

baseList.Add(new Base()); // wrong, collection is actually of of Derived type, and...

Derived d = derivedList[0]; // should actually make an implicit up-cast to work (and fail in this case)

}

So you cant know, at run time, what type is safe for generic cast, unless you limit this type to use "T" only in input or only in output method parameters.

re: LINQ Farm: Covariance and Contravariance in C# 4.0

tytusse — Thu, 18 Dec 2008 23:27:07 GMT

public class Base

{

}

public class Derived : Base

{

}

public class Tests {

public static void Test1() {

List<Derived> derivedList = new List<Derived>();

List<Base> baseList = derivedList; // sounds fair?

baseList.Add(new Base()); // wrong, collection is actually of of Derived type, and...

Derived d = derivedList[0]; // should actually make an implicit up-cast to work (and fail in this case)

}

So you cant know, at run time, what type is safe for generic cast, unless you limit this type to use "T" only in input or only in output method parameters.

그외 새로 들어가는 IDE 기능들

HeeJae's Blog — Sun, 25 Jan 2009 17:41:49 GMT

전에 쓴 post에 있는 새로운 IDE 기능은 dynamic과 COM interop에 관련되어 새로 추가된 기능들이고, 당연히 이 밖에도 여러가지 새로 VS10에 추가 되는 IDE

re: LINQ Farm: Covariance and Contravariance in C# 4.0

OOP Master — Fri, 17 Apr 2009 18:59:16 GMT

Wow, that's intense stuff. Thanks for the summary. Sure, I'll learn about lambduh's, dynamic and functional C# programming features, but seriously, I haven't had OOP problems in C# where I even need to know how to spell variance, covariance and contravariance. Oh, and I have personally released hundred's of thousands of lines of pure C# in production right now for my clients, just one app right now is 557,000 loc that. I bet I could reduce the loc, but at what price, maintainability and readability? No thanks. Small focused classes lead naturally to composition, which is far superior to inheritance for most pattern implementations to get green tests and keep them green.

C# INVARIANZA, COVARIANZA & CONTRAVARIANZA

MVP Factor — Tue, 28 Apr 2009 03:12:59 GMT

Nuestro buen amigo Pete que ya nos ha compartido en el paso muy buenos artículos de XNA, ahora nos comparte