IReadOnlyCollection doesn't have a Contains method

[bollhals]

Why does ICollection have a bool Contains(T item); but not IReadOnlyCollection?
I mean it's clearly a non modifing operation. Does anyone know?

[Joe4evr]

Probably because it's more beneficial for IReadOnlyCollection to be covariant (<out T>) which means T can only appear in the output position of a member signature (aka the return type) in order to abide by that contract. With Contains, the T appears in an input position and therefore means that the entire interface must be invariant, losing the benefits.

[daiplusplus]

I feel that out should allow input-parameter types to be covariant, as it makes sense when working with supertypes sharing object-identity.

Consider:

// *sigh* yup, here comes another OOP inheritance cliché:
class Animal {
}
class Dog : Animal {
}
class Cat : Animal {
}

//

List<Dog> dogs = new List<Dog>()
{
    new Dog( "Clifford" ),
    new Dog( "Benji" ),
    new Dog( "Lassie" )
};

List<Cat> cats = new List<Cat>()
{
    new Cat( "Mufasa" ),
    new Cat( "Catmando" ),
    new Cat( "Bagpuss" )
};

IReadOnlyCollection<Animal> onlyDogs = dogs;
IReadOnlyCollection<Animal> catsAndDogsLivingTogether = Array.Empty<Animal>().Concat( dogs ).Concat( cats ).ToList();

Boolean hasBenji1  = onlyDogs .Contains( dogs[1] ); // Should be true
Boolean hasBenji2  = catsAndDogsLivingTogether.Contains( dogs[1] ); // Should be true

Boolean hasMufasa1 = onlyDogs .Contains( cats.Single( c => c.Name == "Mufasa" ) ); // Should be false
Boolean hasMufasa2 = catsAndDogsLivingTogether.Contains( cats.Single( c => c.Name == "Mufasa" ) ); // Should also be true

...assuming we disregard Linq's EnumerableExtensions.Contains method.

Even though the runtime type of catsAndDogsLivingTogether is List<Animal> (which does have a Contains(Animal) method), of course, it doesn't invalidate my argument though because catsAndDogsLivingTogether could be a HashSet<Animal> where Contains would have O(1) runtime performance (for reference-object-identity) compared to List<T>.Contains' O(n).

Of course, yes, such a thing is impossible to implement at-present, but what if C#/.NET supported covariant input parameters with some compiler smarts? (e.g. hiding methods/compiler-errors when static argument types are provably incompatible, and at runtime the implementation would be given a separate TArg type-argument for the Contains method so the implementations just need simple runtime type-checks to return a default failure) - the idea below is just but what if classes could explicitly implement open generic types?

interface IReadOnlyCollection2<out T>
{
    Boolean Contains<in TArg>( TArg item ) when T : TArg; // <-- Hypothetical syntax
}

class List2<T> : IReadOnlyCollection2<T>
{
    Boolean IReadOnlyCollection2<TArg>.Contains( TArg item ) when T : TArg
    {
        if( item is T t ) return this.Contains( t ); // <-- invoke normal List<T>.Contains(T) below:
        else return false;
    }

    public Boolean Contains2( T item )
    {
        // same as right now
    }
}

So revisiting the cats+dogs example:

List<Cat> catList = new List<Cat>() { ... };
List<Dog> dogList = new List<Dog>() { ... };

Cat mufasa = catList[0];
Dog benji = dogList[0];

IReadOnlyCollection<Cat> catsCollection = catList;
catsCollection.Contains( mufasa ); // --> true // OK!
catsCollection.Contains( benji ); // Compiler error: invocation of `Contains<Dog>` requires `Dog : Cat`, which is not satisfied.

IReadOnlyCollection<Animal> catsAsAnimalCollection = catList;
catsAsAnimalCollection .Contains( mufasa ); // --> true // OK! invocation of `Contains<Cat>` implicitly requires `Cat : Animal` (i.e. `Cat` has a reference-conversion to `Animal`), which is satisfied.
catsAsAnimalCollection .Contains( benji ); // --> false // OK! invocation of `Contains<Dog>` implicitly requires `Dog : Animal` (i.e. `Dog` has a reference-conversion to `Animal`), which is satisfied - but the implementation of `List.Contains<TArg>` sees that `!( TArg item is Cat t is not T )` and so `returns false;`.