8

Can I have a type (for now forgetting its semantics) that can be covariant as well as contravariant?

for example:

public interface Foo<in out T>
{
    void DoFooWith(T arg);
}

Off to Eric Lippert's blog for the meat and potatoes of variance in C# 4.0 as there's little else anywhere that covers adequate ground on the subject.

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.

Suraj
  • 35,905
  • 47
  • 139
  • 250
Water Cooler v2
  • 32,724
  • 54
  • 166
  • 336

1 Answers1

12

No, you cannot do that.

Suppose that were legal. You make an IFoo<Giraffe>. Since IFoo is covariant in T, you can convert it via typesafe reference conversion to IFoo<object>. Since it is contravariant, you can convert that to IFoo<Banana>. What possible semantics are there for IFoo<T> 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<Banana> that returns a Banana, because it might actually be an implementation of IFoo<Giraffe>; how would the author of the implementation know to hand out a Banana? You cannot possibly have a method on IFoo<Banana> that takes a Banana for the same reason; the implementor of IFoo<Giraffe> 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?

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 4
    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
  • 2
    @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
  • 2
    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
  • 1
    Eric, I've been studying variance for the last couple of days and I think I've finally grokked it. Thank you. You're awesome! You're my hero! – Water Cooler v2 May 18 '10 at 21:00