Search code examples
vb.netc#-4.0syntaxlanguage-designlanguage-features

Syntax choice for type parameter variance in C# and VB


In both C# and VB, type parameter modifiers are used to express the variance of type parameters. For example, the C# version looks like:

interface Foo<in X, out Y> { }

and the VB version looks like:

Interface Foo(Of In X, Out Y)

End Interface

Since variance specifications basically restrict where and how a type parameter can be used, I tend to think of them as additional constraints on type parameters.

I'm just curious as to why they aren't represented so. I mean, why are they represented in both languages as additional modifiers on type parameters, instead of being added to the type constraint list? If they were type constraints, the C# version would've looked like:

interface Foo<X, Y> where X:in where Y:out { }

and the VB version would've looked like:

Interface Foo(Of X As In, Y As Out)

End Interface

So, does anyone know if there was some reasoning behind the particular syntax choice for expressing type parameter variance in these languages, or was it just random?


Solution

  • I think the language designers made a good choice here.

    The reason for this is that covariance and contravariance are not constraints on the type (X/Y in your case), but rather on the interface itself.

    If you used the where X: in or Of X As In syntax, you're suggesting a constraint on the type X. However, covariance and contravariance are really "constraints" on the interface itself - how the generic type of interface is going to use the type "T". For example, by saying:

    interface Foo<out X> {}
    

    You're saying "This interface only uses X as an output", which really is saying that you're constraining your usage of X in a way that allows covariance.

    This is very different than saying "X needs to be constrainted to a specific type", since this isn't a constraint on X.

    By introducing a new syntax, the language designers have allowed us to conceptualize this more effectively by not mixing messages.