Cannot implicitly convert List<T> to Collection<T>

This is a compiler error (slightly changed for readability).

This one always puzzled me. FxCop tells that this is a bad thing to return List and classes that are\derived from Collection<T> should be preferrable as return types.

Also, FxCop says that it is OK to use List<T> for internal data storage\manipulation. Ok, I get it, but what I don't get is that compiler complains about trying to implicitly convert List<T> to Collection<T>. Isn't List<T> more interface-charged and functional? Why prohibit implicit conversion?

And another question that stems from above: is new List<int>(some collection<int>) constructor expensive?

Thank you,

Valentin Vasiliev

Why not just do the following:

Collection<string> collection = new Collection<string>(theList);

as Collection(IList input) takes a List as part of construction.

List<T> doesn't derive from Collection<T> - it does, however, implement ICollection<T>. That would be a better choice of return type.

As for the new List<int>(some collection<int>) question - it partly depends on what the collection is. If it implements ICollection<T> (at execution time) then the constructor can use its Count property to create the list with the right initial capacity before iterating through it and adding each item. If it doesn't implement ICollection<T> then it's just equivalent to:

List<int> list = new List<int>();
foreach (int x in otherCollection)
{
    list.Add(x);
}

Still nice to have in a convenient constructor, but not hugely efficient - it can't be, really.

I don't believe the constructor does anything cunning for arrays, which it potentially could - using Array.Copy or whatever to just copy the lot in one go rather than iterating though. (Likewise if it were another List<T> it could get at the backing array and copy that directly.)