Covariance contravariance inconvenience

I love the covariance/contavariance support in C#4. That is the mechanism that lets you implicitly convert from an IEnumerable<Child> to an IEnumerable<Parent> was expected (covariance), and an IComparable<Parent> can be converted to IComparable<Child> (contravariance). Here Child obviously inherits from Parent.

One of the biggest problems though is that this only works for classes and interfaces where the type parameters are either all outbound or all inbound for covariance and contravariance respectively. E.g. no methods on IEnumerable<T> accept T, which is covariance. And no methods on IComparable<T> return T. Eric Lippert wrote a bunch of posts worth reading about while the compiler team were considering variance.

This is somewhat inconvenient. For example it means that IList<Child> cannot be assigned to IList<Parent>, or vice-versa, because IList<T> methods both accept and return T. And often one may wish to write a method using IList<T> rather than IEnumerable<T> as it allows for direct element access. It is particularly frustrating because I may well only need to use the methods that read from the list, and so if IReadonlyList<T> existed then all might be sweet.

Now I was wrestling with this kind of thing the other day when I read Lippert's post on What is this thing called a Type, which got me thinking about it all again. Here he's again talking about how various operations tranform one Type into another.

OK, to the point. Here's the idea I was thinking. What if it were possible to create modified types based on existing interfaces and classes that only present the input or output methods.

For example (and to use Lippert's Giraffe inherits from Mammal inherits from Animal example):
IList<out Mammal> and IList<in Mammal> becomes types that are declarable in code.

IList<out Mammal> exposes only the subset of IList<Mammal> that is covariant. I.e. the methods for reading from the list, but none of the methods that accept T parameters. IList<out Giraffe> could be assigned to IList<out Mammal>. As a type, IList<out Mammal> itself would be smaller than IList<Mammal>, so it is always possible to convert from IList<Mammal> to IList<out Mammal>. So, finally IList<Giraffe> could be assigned to IList<out Mammal>.

Likewise, IList<in Mammal> exposes only the subset of IList<Mammal> that is contravarient, exposing only the methods for modifying a list. By the same (but contravariant) argument, IList<Giraffe> would be assignable to IList<in Mammal>.

Some code we could then write:

static void FeedMammals(IList<out Mammal> mammals)
{
  // mammals.Count is available as it doesn't use the type parameter.
  // Using an old-style for-loop to illustrate we don't want to use IEnumerable<T>
  for (int i=0; i<mammals.Count; i++)    parameter
  {
      // only the getter is available, as it is outbound
      mammals[i].FeedMammalFood();
  }

  // But these are illegal:
  mammals[0] = new Mammal(); // setter
  mammals.Insert(0, new Mammal()); // method that accepts T
}

And call with:

List<Giraffe> giraffes = ...;
FeedMammals(giraffes);  // yay, cast from List<Giraffe> to IList<out Mammal>

Similarly we could have:

static void AddBabyMammals(IList<in Mammal> mammals)
{
  // New baby born
  Mammal baby = GetNewBabyMammal();
  mammals.Insert(0, baby);

  //Setter is also OK to replace a value
  mammals[0] = baby;

  // But these would be illegal
  Mammal m1 = mammals[0]; // getter
  foreach (var m2 in mammals) // call to enumarator, because its 'out'
}

And call with:

List<Animal> animals = ...;
AddBabyMammals(animals);  // yay, cast from List<Giraffe> to IList<out Mammal>

This would be a wonderful feature. Anyway, that's my two cents.