Can I have a type that's both, covariant and contravariant, i.e. fully fungible/changeable with sub and super types?

No, you cannot do that Suppose that were legal. You make an IFooYou cannot possibly have a method on IFoo.

No, you cannot do that. Suppose that were legal. You make an IFoo.

Since IFoo is covariant in T, you can convert it via typesafe reference conversion to IFoo. Since it is contravariant, you can convert that to IFoo. What possible semantics are there for IFoo such that it makes sense to be able to convert an IFoo of Giraffes to an IFoo of Bananas via reference conversion?

Giraffes and Bananas have nothing in common other than being reference types. You cannot possibly have a method on IFoo that returns a Banana, because it might actually be an implementation of IFoo; how would the author of the implementation know to hand out a Banana? You cannot possibly have a method on IFoo that takes a Banana for the same reason; the implementor of IFoo is expecting you to hand him a Giraffe.

Here's another way of looking at it: "in T" means (roughly) "T appears only in input positions". "out T" means (roughly) "T appears only in output positions". Therefore "in out T" would mean... what?

As we've seen already, it can only mean "T does not appear at all in any method or property. " What's the point of making a generic type in T where you never use T?

Actually, generic types which don't use their generic type arguments can be extremely useful. So called "phantom types" enable code to be written in such a way that incorrect operations can be statically disallowed. The canonical example is probably a File type, where the type T encodes whether the file allows reading, writing, or both even though the internals of the class never reference T.

– kvb May 14 '10 at 19:41 Of course, you could easily violate the safety benefit of phantom types if the type were annotated as both covariant and contravariant, since you could then convert a File to a File, as you note. – kvb May 14 '10 at 20:50 1 @kvb: How is that any different from simply making a base class File and derived classes "WritableFile", "ReadableFile" and "ReadableAndWritableFile"? Why capture something in the generic type system when it could simply be captured in the ordinary type system?

– Eric Lippert May 14 '10 at 22:28 Well, since . NET doesn't support multiple inheritance, having ReadableAndWriteableFile derive from ReadableFile and WriteableFile is not possible. However, you'd like to be able to pass in a ReadableAndWriteableFile wherever a method expects a ReadableFile, for instance.

– kvb May 14 '10 at 22:42 Perhaps a more compelling example would be a strongly typed wrapper around ILGenerator for using Reflection.Emit. You could use phantom types to represent the current stack, so that e.g. A br. True instruction can only be emitted if the top of the stack is a boolean value.

– kvb May 14 '10 at 22:52.

I tried it out anyway, not only does it not allow that, but it tells me I am missing the whole point. I need to understand the link between read-only, write-only and variance. I guess I got some more reading to do.

But any short, epiphany inducing answers are welcome, meanwhile.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.