c# - Is returning IList<T> worse than returning T[] or List<T>?

Question

The answers to questions like this: List<T> or IList<T> always seem to agree that returning an interface is better than returning a concrete implementation of a collection. But I'm struggling with this. Instantiating an interface is impossible, so if your method is returning an interface, it's actually still returning a specific implementation. I was experimenting a bit with this by writing 2 small methods:

public static IList<int> ExposeArrayIList()
{
    return new[] { 1, 2, 3 };
}

public static IList<int> ExposeListIList()
{
    return new List<int> { 1, 2, 3 };
}

And use them in my test program:

static void Main(string[] args)
{
    IList<int> arrayIList = ExposeArrayIList();
    IList<int> listIList = ExposeListIList();

    //Will give a runtime error
    arrayIList.Add(10);
    //Runs perfectly
    listIList.Add(10);
}

In both cases when I try to add a new value, my compiler gives me no errors, but obviously the method which exposes my array as an IList<T> gives a runtime error when I try to add something to it. So people who don't know what's happening in my method, and have to add values to it, are forced to first copy my IList to a List to be able to add values without risking errors. Of course they can do a typecheck to see if they're dealing with a List or an Array, but if they don't do that, and they want to add items to the collection they have no other choice to copy the IList to a List, even if it already is a List. Should an array never be exposed as IList?

Another concern of mine is based upon the accepted answer of the linked question (emphasis mine):

If you are exposing your class through a library that others will use, you generally want to expose it via interfaces rather than concrete implementations. This will help if you decide to change the implementation of your class later to use a different concrete class. In that case the users of your library won't need to update their code since the interface doesn't change.

If you are just using it internally, you may not care so much, and using List may be ok.

Imagine someone actually used my IList<T> they got from my ExposeListIlist() method just like that to add/remove values. Everything works fine. But now like the answer suggests, because returning an interface is more flexible I return an array instead of a List (no problem on my side!), then they're in for a treat...

TLDR:

1) Exposing an interface causes unnecessary casts? Does that not matter?

2) Sometimes if users of the library don't use a cast, their code can break when you change your method, even though the method remains perfectly fine.

I am probably overthinking this, but I don't get the general consensus that returning an interface is to be preferred over returning an implementation.

Answer 1

Maybe this is not directly answering your question, but in .NET 4.5+, I prefer to follow these rules when designing public or protected APIs:

• do return IEnumerable<T>, if only enumeration is available;
• do return IReadOnlyCollection<T> if both enumeration and items count are available;
• do return IReadOnlyList<T>, if enumeration, items count and indexed access are available;
• do return ICollection<T> if enumeration, items count and modification are available;
• do return IList<T>, if enumeration, items count, indexed access and modification are available.

Last two options assume, that method must not return array as IList<T> implementation.