Question

I’m unclear as to why the following code snippet isn’t covarient?

  public interface IResourceColl<out T> : IEnumerable<T> where T : IResource {

    int Count { get; }

    T this[int index] { get; }

    bool TryGetValue( string SUID, out T obj ); // Error here?
    }

Error 1 Invalid variance: The type parameter ‘T’ must be invariantly
valid on ‘IResourceColl.TryGetValue(string, out T)’. ‘T’ is
covariant.

My interface only uses the template parameter in output positions. I could easily refactor this code to something like

  public interface IResourceColl<out T> : IEnumerable<T> where T : class, IResource {

    int Count { get; }

    T this[int index] { get; }

    T TryGetValue( string SUID ); // return null if not found
    }

but I’m trying to understand if my original code actually violates covariance or if this is a compiler or .NET limitation of covariance.

Answer 1

The problem is indeed here:

bool TryGetValue( string SUID, out T obj ); // Error here?

You marked obj as out parameter, that still means though that you are passing in obj so it cannot be covariant, since you both pass in an instance of type T as well as return it.

Edit:

Eric Lippert says it better than anyone I refer to his answer to “ref and out parameters in C# and cannot be marked as variant” and quote him in regards to out parameters:

Should it be legal to make T marked as “out”? 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.