Xtykutl

I have a type Shelter that needs to be covariant, so that an override in another class* can return a Shelter<Cat> where a Shelter<Animal> is expected. Since classes cannot be co- or contravariant in C#, I added an interface:

public interface IShelter<out AnimalType>

{

    AnimalType Contents { get; }

}

However, there is a place where an IShelter (compile-time type) is assigned a new animal, where we know for sure that the animal being set is going to be a Cat. At first, I thought I could just add a set to the Contents property and do:

IShelter<Cat> shelter = new Shelter(new Cat());

shelter.Contents = new Cat();

But adding the setter is not possible;

Error   CS1961  Invalid variance: The type parameter 'AnimalType' must be invariantly valid on 'IShelter<AnimalType>.Contents'. 'AnimalType' is covariant.

This makes sense, because otherwise I could pass the catshelter to this function:

private static void UseShelter(IShelter<Animal> s)

{

    s.Contents = new Lion();

}

However, I'm not going to do that. It would be nice to have some way to mark the setter as invariant so that the UseShelter function would only be able to assign an Animal, and so that this would be enforced at compile-time. The reason I need this is because there is a place in my code that knows it has a Shelter<Cat>, and needs to re-assign the Contents property to a new Cat.

The workaround I found so far is to add a jucky runtime type check in an explicit set function; Juck!

public void SetContents(object newContents)

{

    if (newContents.GetType() != typeof(AnimalType))

    {

        throw new InvalidOperationException("SetContents must be given the correct AnimalType");

    }

    Contents = (AnimalType)newContents;

}

The parameter needs to be of type object, so that this function can be specified in the interface. Is there any way to enforce this at compile-time?

* To clarify, there is a function: public virtual IShelter<Animal> GetAnimalShelter() that is overridden and returns an IShelter<Cat>:

public override IShelter<Animal> GetAnimalShelter(){

    IShelter<Cat> = new Shelter<Cat>(new Cat());

}

A minimal working example including most of the code above follows:

class Animal { }

class Cat : Animal { }

class Lion : Animal { }



public interface IShelter<out AnimalType>

{

    AnimalType Contents { get; }



    void SetContents(object newContents);

}



class Shelter<AnimalType> : IShelter<AnimalType>

{

    public Shelter(AnimalType animal)

    {

    }



    public void SetContents(object newContents)

    {

        if (newContents.GetType() != typeof(AnimalType))

        {

            throw new InvalidOperationException("SetContents must be given the correct AnimalType");

        }

        Contents = (AnimalType)newContents;

    }



    public AnimalType Contents { get; set; }

}



class Usage

{

    public static void Main()

    {

        IShelter<Cat> catshelter = new Shelter<Cat>(new Cat());

        catshelter.SetContents(new Cat());

        catshelter.SetContents(new Lion()); // should be disallowed by the compiler

    }

}

In a case like this, just remove the setter from the interface and use the concrete type (or infer it using var as in this example). After all, if the code "knows" for sure it is adding a cat, it probably also knows the shelter's concrete type.

interface IShelter<out AnimalType>

{

    AnimalType Contents { get; }

}



class Shelter<AnimalType> : IShelter<AnimalType>

{

    public Shelter(AnimalType animal)

    {

    }



    public void SetContents(AnimalType newContents)

    {

        Contents = newContents;

    }



    public AnimalType Contents { get; set; }

}



public class Usage

{

    public static void Main()

    {

        var catshelter = new Shelter<Cat>(new Cat());

        catshelter.SetContents(new Cat());

        catshelter.SetContents(new Lion()); // Is disallowed by the compiler

    }

}

Example on DotNetFiddle

The same pattern is followed by many CLR classes under System.Collections.Generic. Lots of classes implement IEnumerable<T>, which is covariant; but if you want to call the methods that allow you to add, you have to reference it as a concrete class such as List<T>. Or if you really want to add via an interface you could use IList<T>. But in no case is there a single covariant interface that also allows you to add.

The only solution I could think of so far would be using 2 separate interfaces for each of your concerns (IShelter and ISpecificShelter):

// this replaces IShelter<Animal>

public interface IShelter

{

    Animal Animal { get; set; }

}



// this replaces IShelter<SpecificAnimal>

public interface ISpecificShelter<AnimalType> : IShelter where AnimalType : Animal

{

    new AnimalType Animal { get; set; }

}



// implementation

public class Shelter<AnimalType> : ISpecificShelter<AnimalType> where AnimalType : Animal

{

    private Animal _animal;



    // explicit implementation, so the correct implementation is called depending on what interface is used

    Animal IShelter.Animal { get { return _animal; } set { _animal = value; } }

    AnimalType ISpecificShelter<AnimalType>.Animal { get { return (AnimalType)_animal; } set { _animal = value; } }



    public Shelter()

    { }

}

Usage:

// specific animal

ISpecificShelter<Cat> catShelter = new Shelter<Cat>();

catShelter.Animal = new Cat();

catShelter.Animal = new Lion(); // => compiler error!

Cat cat = catShelter.Animal;



// cast to general interface

IShelter shelter = catShelter;

Animal animal = shelter.Animal;

If you want to prevent instancing the class directly, but only work with the interfaces, you could implement a factory pattern:

public static class Shelter

{

    public static IShelter Create()

    {

        return new Implementation<Animal>();

    }



    public static IShelter Create(Animal animal)

    {

        return new Implementation<Animal>(animal);

    }



    public static ISpecificShelter<AnimalType> Create<AnimalType>() where AnimalType : Animal

    {

        return new Implementation<AnimalType>();

    }



    public static ISpecificShelter<AnimalType> Create<AnimalType>(AnimalType animal) where AnimalType : Animal

    {

        return new Implementation<AnimalType>(animal);

    }



    private class Implementation<AnimalType> : ISpecificShelter<AnimalType> where AnimalType : Animal

    {

        private Animal _animal;



        Animal IShelter.Animal { get { return _animal; } set { _animal = value; } }

        AnimalType ISpecificShelter<AnimalType>.Animal { get { return (AnimalType)_animal; } set { _animal = value; } }



        public Implementation()

        { }



        public Implementation(AnimalType animal)

        {

            _animal = animal;

        }

    }

}

Usage:

var shelter = Shelter.Create();

shelter.Animal = new Lion();

// OR:

// var shelter = Shelter.Create(new Lion());

var animal = shelter.Animal;



var catShelter = Shelter.Create<Cat>();

catShelter.Animal = new Cat();

// OR:

// var catShelter = Shelter.Create(new Cat());

var cat = catShelter.Animal;



// cast is also possible:

shelter = (IShelter)catShelter;

It really depends on your specific use cases. You should provide more examples and information on what exactly you want to do and why.

What you are trying to achieve is not possible, because technically you want to have interface which is both covariant and contravariant. Limitations of each type of variance are well explained here in this SO answer

So, if you want to be able to set more derived type (e.g TDerived : T) to the Contents property, you should use contravariant interface:

public interface IShelter<in T>

{

    T Contents { set; }

}

On the other hand, if you want to be able to pass Contents to less derived type (e.g. T : TBase), you should stick with your current implementation:

public interface IShelter<out T>

{

    T Contents { get; }

}

Any other combination would result in possible runtime errors, that's why the compiler doesn't allow you to have an interface which is both co- and contravariant.

So, either use two distinct interfaces to achieve what you want, or rethink/polish your architecture around these types.