Why can't I use output parameters with covariant generic types?

Question

I tried the following, and the result is in the interface names:

interface NotOK<out T>
{
    bool TryDequeue(out T t);
}

interface OK<out T>
{
    T TryDequeue(out bool b);
}

The docs have this to say:

ref and out parameters in C# cannot be variant.

Why a ref cannot be covariant (or contravariant, for that matter) is obvious, but why can out parameters not be covariant, the same way that method results are?

Is it a compiler limitation or could out parameters in fact break the covariance constraints?

`out` the way you use it here is not so much different from `ref` (difference: it is used only as output, not as input) - look at the reference — Random Dev, Jul 03 '14 at 04:28
possible duplicate of [ref and out parameters in C# and cannot be marked as variant](http://stackoverflow.com/questions/2876315/ref-and-out-parameters-in-c-sharp-and-cannot-be-marked-as-variant) — Evgeniy Berezovsky, Sep 24 '14 at 23:39

score 1 · Accepted Answer · edited May 23 '17 at 11:57

My question actually had an answer already at ref and out parameters in C# and cannot be marked as variant

A relevant bit of Eric Lippert's great answer (but there's more):

Unfortunately no. "out" actually is not different than "ref" behind the scenes. The only difference between "out" and "ref" is that the compiler forbids reading from an out parameter before it is assigned by the callee, and that the compiler requires assignment before the callee returns normally. Someone who wrote an implementation of this interface in a .NET language other than C# would be able to read from the item before it was initialized, and therefore it could be used as an input. We therefore forbid marking T as "out" in this case. That's regrettable, but nothing we can do about it; we have to obey the type safety rules of the CLR.

score 0 · Answer 2 · answered Sep 19 '14 at 15:24

It is because compiler might think an unsafe type casting is needed if you use 'out' parameter modifier for covariance.

See this scenario. Say there is a method f expecting NotOK as input:

interface NotOK<out T>
{
    bool TryDequeue(out T t);
}

void f( NotOK<Animal> x)
{
   bool b ;
   Animal animal_in_f;
   b = x.TryDequeue(animal_in_f);
}

See what happens if I have two interfaces:

NotOK<Animal> objA;
NotOK<Dog> objD;

Use objA as input to f, no problem.

f(objA);
// objA should have a method of signature bool TryDequeue(out Animal t)
// inside method f, it calls x.TryDequeue(animal_in_f); 
// where animal_in_f is Animal, type match

But if covariance is allowed, passing objD would be allowed

f(objD);
// objD should have a method of signature bool TryDequeue(out Dog t)
// inside method f, it calls x.TryDequeue(animal_in_f); 
// where animal_in_f is Animal
// but this time x.TryDequeue is expecting a Dog!!
// It is unsafe to cast animal_in_f to Dog

So you see why out is not allowed to use in covariance.

I think conceptually it should work, because by using out parameter modifier we just want that passed variable as output. It will work if compiler has a special rule so that when it encounters scenario as above it should consider the casting is safe and not generate error.

However I think C# designer weighted the pros and cons and finally decided to maintain a consistent type checking rule, which is downcasting is not allowed in general.

In my opinion it is better to add that special rule because now it limits the usage, say it cannot have a method that return two objects of T type which needs the use of out parameter modifier.

Why can't I use output parameters with covariant generic types?

2 Answers2