Currently .NET languages such as VB and C# do not support covariance and contravariance for generics. This is not likely to chance in the near future, though people at Microsoft are talking about it. A full introduction to covariance and contravariance would take too long. For that we ask reader's turn to Eric Lippert's series on Covariance and Contravariance in C#.
In order to add support for covariant and contravariant generic types in VB, Lucian Wischik has proposed the following syntax.
Type parameters can be decorated with the keywords "In" and "Out. An "In" type is a type that can only appear as a method parameter. Likewise, an "Out" type is one that would only appear as the return type of a method.
An example of where Out types would be useful is IEnumerable(Of T). If a function is expecting an IEnumerable(Of Animal), giving it an IEnumerable(of Bird) should work under all circumstances. For In types, a somewhat contrived example is in order. Consider this interface:
Interface IWriter(Of T)
Write(value As T)
If you pass an IWriter(Of Bird) to a function expecting an IWriter(Of Animal), clearly it would not work. The method could pass any subclass of Animal to IWriter.Write, though only Birds are supported.
With the annotations, the interfaces would look like:
Interface IEnumerable(Of Out T)
Interface IWriter(Of In T)
While this was proposed for VB, it could also be used in C#.
interface IEnumerable<out T>
interface IWriter<in T>
Unfortunately this syntax doesn't directly work in the most common scenarios. Consider IList(Of T). When passing to methods that write to the collection, T should be an In type. But when passing to methods that read from the collection, it should be an Out type. Perhaps the solution here is to retroactively create base classes for IList that separate the methods that accept a T value from the ones that return one.
On a historical note, C# and VB both support array covariance (out/IEnumerable scenario) even though it can lead to runtime errors in contravariant situations (in/IWriter scenario). This was done in order to make C# more compatible with Java. This is generally considered a poor decision, but it cannot be undone at this time.