Immutability in C# Part Three: A Covariant Immutable Stack

WAW!!! What a serie of blog posts for "Covariance and Contravariance" - C# Future...

Journal of Abu Sayed Mohammad Ismail — Thu, 18 Dec 2008 16:22:59 GMT

So nicely step by step blogged by Eric Lippert for "Covariance and Contravariance" as "Fabulous

re: Immutability in C# Part Three: A Covariant Immutable Stack

Rob Paveza — Fri, 17 Oct 2008 21:16:49 GMT

Hi Eric,

I've just read through pretty much your entire series on covariance and contravariance. I'd certainly love to see support for it (and it may start making its way into my blog series on my C# wishlist), but I have to say: I don't like the example in this blog post.

Above all, I don't like that we've created a new imaginary interface IStack<+T> that has every operation for a stack *except* for Push(). A Stack is a well-known and well-understood data structure - they even talked about it at university! - and to create an interface, which models behavior, but to not include all of the behavior for the explicit purpose of supporting a language feature seems wrong. It feels like coincidental cohesion.

I also have a substantial problem with the use of an extension method to implement Push(). I've mentioned this in at least two talks I've presented on C# 3.0 and extension methods, not to mention my blog: Extension methods allow developers to feel like they have a twisted kind of multiple inheritance, except that it's not MI at all because there's no virtual method. The compiler, and consequently the runtime, binds to the extension method unless it can explicitly resolve the method on the defining class or interface, but even if the real implementation class was Stack<T> which implements Push(), but the variable is declared as IStack<+T>, we'll use the extension method. This is a scary thought when you consider applying this solution to non-data-structure classes with virtual methods that are no longer making virtual calls.

Now, to qualify: I've never said that extension methods are bad; I've simply said that software developers need to be cognizant of the fact that they might not always be calling what they think they're calling. IntelliSense and the compiler make it feel like we're operating on a real behavior of objects.

FWIW, I saw someone else post syntax such as:

delegate U Action<* is T, U is *<(T item);

I think that's fantastic syntax. :)

Immutability in C#

Community Blogs — Thu, 17 Jan 2008 02:45:15 GMT

For some reason, there's been a lot of buzz lately around immutability in C#. If you're interested in

re: Immutability in C# Part Three: A Covariant Immutable Stack

Eric Lippert — Wed, 19 Dec 2007 22:44:47 GMT

The point of this was that IF we add covariance to the language in some future version, THEN this would work. We have not yet added covariance, so this does not work.

See my recent ten part series on covariance for more details.

re: Immutability in C# Part Three: A Covariant Immutable Stack

cipto — Wed, 19 Dec 2007 09:34:09 GMT

Hi, em i try ur code

Where to put this code below,so the code can work:

public static class Extensions

{

public static IStack<T> Push<T>(this IStack<T> s, T t)

{

return Stack<T>.Push(t, s);

}

IStack<+T> , + is unexpected token

how come + generate error

is this for .net 2.0 or not?

Please give me a complete listing code, so i can follow this one,

i've followed your part one and two and success.

re: Immutability in C# Part Three: A Covariant Immutable Stack

David — Thu, 13 Dec 2007 23:20:50 GMT

So you did :) Looks like I have a lot more reading to do.

re: Immutability in C# Part Three: A Covariant Immutable Stack

Eric Lippert — Thu, 13 Dec 2007 02:54:48 GMT

Yes. I just wrote a ten part series of blog posts on exactly that subject.

re: Immutability in C# Part Three: A Covariant Immutable Stack

David — Thu, 13 Dec 2007 02:29:50 GMT

Will the hypothetical covariant C# have a way of enforcing covariantability (is that a word)? For example, would it be possible to add a "covariant" keyword to a type definition, and then have the compiler enforce that all operations in that type are covariant?

re: Immutability in C# Part Three: A Covariant Immutable Stack

Gilles Michard — Fri, 07 Dec 2007 13:05:58 GMT

Is there a hope that anonymous types { Ta a, Tb b} would implement the covariant interface

interface IAnonymous_a_b<+Ta,+Tb>{

Ta a { get;}

Tb b { get;}

}

Combined with an automatic type inference (most derived compatible type) , it would really help with Enumerable.Concat when using different types (casting to an anonymous type is not possible)

Perhaps VB will do that if not C#?

re: Immutability in C# Part Three: A Covariant Immutable Stack

Eric Lippert — Fri, 07 Dec 2007 10:18:46 GMT

> IStack<Mammal> sm4 = sm3.Push(new Tiger("Tony")) is actually

> IStack<Mammal> sm4 = sm3.Push<Tiger>(new Tiger("Tony"))

> because the type is inferred from from type of the parameter that the method is called with

Nope. Did you actually try it? (Obviously the covariant conversion will not work, but this call will.)

Hint: the type argument for the generic method is inferred from more than just the "new Tiger" parameter.