How do arrays in C# partially implement IList<T>?

Question

So as you may know, arrays in C# implement IList<T>, among other interfaces. Somehow though, they do this without publicly implementing the Count property of IList<T>! Arrays have only a Length property.

Is this a blatant example of C#/.NET breaking its own rules about the interface implementation or am I missing something?

Solution 1

New answer in the light of Hans's answer

Thanks to the answer given by Hans, we can see the implementation is somewhat more complicated than we might think. Both the compiler and the CLR try very hard to give the impression that an array type implements IList<T> - but array variance makes this trickier. Contrary to the answer from Hans, the array types (single-dimensional, zero-based anyway) do implement the generic collections directly, because the type of any specific array isn't System.Array - that's just the base type of the array. If you ask an array type what interfaces it supports, it includes the generic types:

foreach (var type in typeof(int[]).GetInterfaces())
{
    Console.WriteLine(type);
}

Output:

System.ICloneable
System.Collections.IList
System.Collections.ICollection
System.Collections.IEnumerable
System.Collections.IStructuralComparable
System.Collections.IStructuralEquatable
System.Collections.Generic.IList`1[System.Int32]
System.Collections.Generic.ICollection`1[System.Int32]
System.Collections.Generic.IEnumerable`1[System.Int32]

For single-dimensional, zero-based arrays, as far as the language is concerned, the array really does implement IList<T> too. Section 12.1.2 of the C# specification says so. So whatever the underlying implementation does, the language has to behave as if the type of T[] implements IList<T> as with any other interface. From this perspective, the interface is implemented with some of the members being explicitly implemented (such as Count). That's the best explanation at the language level for what's going on.

Note that this only holds for single-dimensional arrays (and zero-based arrays, not that C# as a language says anything about non-zero-based arrays). T[,] doesn't implement IList<T>.

From a CLR perspective, something funkier is going on. You can't get the interface mapping for the generic interface types. For example:

typeof(int[]).GetInterfaceMap(typeof(ICollection<int>))

Gives an exception of:

Unhandled Exception: System.ArgumentException: Interface maps for generic
interfaces on arrays cannot be retrived.

So why the weirdness? Well, I believe it's really due to array covariance, which is a wart in the type system, IMO. Even though IList<T> is not covariant (and can't be safely), array covariance allows this to work:

string[] strings = { "a", "b", "c" };
IList<object> objects = strings;

... which makes it look like typeof(string[]) implements IList<object>, when it doesn't really.

The CLI spec (ECMA-335) partition 1, section 8.7.1, has this:

A signature type T is compatible-with a signature type U if and only if at least one of the following holds

...

T is a zero-based rank-1 array V[], and U is IList<W>, and V is array-element-compatible-with W.

(It doesn't actually mention ICollection<W> or IEnumerable<W> which I believe is a bug in the spec.)

For non-variance, the CLI spec goes along with the language spec directly. From section 8.9.1 of partition 1:

Additionally, a created vector with element type T, implements the interface System.Collections.Generic.IList<U>, where U := T. (§8.7)

(A vector is a single-dimensional array with a zero base.)

Now in terms of the implementation details, clearly the CLR is doing some funky mapping to keep the assignment compatibility here: when a string[] is asked for the implementation of ICollection<object>.Count, it can't handle that in quite the normal way. Does this count as explicit interface implementation? I think it's reasonable to treat it that way, as unless you ask for the interface mapping directly, it always behaves that way from a language perspective.

What about ICollection.Count?

So far I've talked about the generic interfaces, but then there's the non-generic ICollection with its Count property. This time we can get the interface mapping, and in fact the interface is implemented directly by System.Array. The documentation for the ICollection.Count property implementation in Array states that it's implemented with explicit interface implementation.

If anyone can think of a way in which this kind of explicit interface implementation is different from "normal" explicit interface implementation, I'd be happy to look into it further.

Old answer around explicit interface implementation

Despite the above, which is more complicated because of the knowledge of arrays, you can still do something with the same visible effects through explicit interface implementation.

Here's a simple standalone example:

public interface IFoo
{
    void M1();
    void M2();
}

public class Foo : IFoo
{
    // Explicit interface implementation
    void IFoo.M1() {}

    // Implicit interface implementation
    public void M2() {}
}

class Test    
{
    static void Main()
    {
        Foo foo = new Foo();

        foo.M1(); // Compile-time failure
        foo.M2(); // Fine

        IFoo ifoo = foo;
        ifoo.M1(); // Fine
        ifoo.M2(); // Fine
    }
}

Solution 2

So as you may know, arrays in C# implement IList<T>, among other interfaces

Well, yes, erm no, not really. This is the declaration for the Array class in the .NET 4 framework:

[Serializable, ComVisible(true)]
public abstract class Array : ICloneable, IList, ICollection, IEnumerable, 
                              IStructuralComparable, IStructuralEquatable
{
    // etc..
}

It implements System.Collections.IList, not System.Collections.Generic.IList<>. It can't, Array is not generic. Same goes for the generic IEnumerable<> and ICollection<> interfaces.

But the CLR creates concrete array types on the fly, so it could technically create one that implements these interfaces. This is however not the case. Try this code for example:

using System;
using System.Collections.Generic;

class Program {
    static void Main(string[] args) {
        var goodmap = typeof(Derived).GetInterfaceMap(typeof(IEnumerable<int>));
        var badmap = typeof(int[]).GetInterfaceMap(typeof(IEnumerable<int>));  // Kaboom
    }
}
abstract class Base { }
class Derived : Base, IEnumerable<int> {
    public IEnumerator<int> GetEnumerator() { return null; }
    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return GetEnumerator(); }
}

The GetInterfaceMap() call fails for a concrete array type with "Interface not found". Yet a cast to IEnumerable<> works without a problem.

This is quacks-like-a-duck typing. It is the same kind of typing that creates the illusion that every value type derives from ValueType which derives from Object. Both the compiler and the CLR have special knowledge of array types, just as they do of value types. The compiler sees your attempt at casting to IList<> and says "okay, I know how to do that!". And emits the castclass IL instruction. The CLR has no trouble with it, it knows how to provide an implementation of IList<> that works on the underlying array object. It has built-in knowledge of the otherwise hidden System.SZArrayHelper class, a wrapper that actually implements these interfaces.

Which it doesn't do explicitly like everybody claims, the Count property you asked about looks like this:

    internal int get_Count<T>() {
        //! Warning: "this" is an array, not an SZArrayHelper. See comments above
        //! or you may introduce a security hole!
        T[] _this = JitHelpers.UnsafeCast<T[]>(this);
        return _this.Length;
    }

Yes, you can certainly call that comment "breaking the rules" :) It is otherwise darned handy. And extremely well hidden, you can check this out in SSCLI20, the shared source distribution for the CLR. Search for "IList" to see where the type substitution takes place. The best place to see it in action is clr/src/vm/array.cpp, GetActualImplementationForArrayGenericIListMethod() method.

This kind of substitution in the CLR is pretty mild compared to what happens in the language projection in the CLR that allows writing managed code for WinRT (aka Metro). Just about any core .NET type gets substituted there. IList<> maps to IVector<> for example, an entirely unmanaged type. Itself a substitution, COM doesn't support generic types.

Well, that was a look at what happens behind the curtain. It can be very uncomfortable, strange and unfamiliar seas with dragons living at the end of the map. It can be very useful to make the Earth flat and model a different image of what's really going on in managed code. Mapping it to everybody favorite answer is comfortable that way. Which doesn't work so well for value types (don't mutate a struct!) but this one is very well hidden. The GetInterfaceMap() method failure is the only leak in the abstraction that I can think of.

Solution 3

IList<T>.Count is implemented explicitly:

int[] intArray = new int[10];
IList<int> intArrayAsList = (IList<int>)intArray;
Debug.Assert(intArrayAsList.Count == 10);

This is done so that when you have a simple array variable, you don't have both Count and Length directly available.

In general, explicit interface implementation is used when you want to ensure that a type can be used in a particular way, without forcing all consumers of the type to think about it that way.

Edit: Whoops, bad recall there. ICollection.Count is implemented explicitly. The generic IList<T> is handled as Hans descibes below.

Solution 4

Explicit interface implementation. In short, you declare it like void IControl.Paint() { } or int IList<T>.Count { get { return 0; } }.

Solution 5

It's no different than an explicit interface implementation of IList. Just because you implement the interface doesn't mean its members need to appear as class members. It does implement the Count property, it just doesn't expose it on X[].

View more solutions

Comments

[user541686]

No one said the Array class had to be written in C#!

[CodesInChaos]

Array is a "magic" class, that couldn't be implemented in C# or any other language targeting .net. But this specific feature is available in C#.

[Tim S.]

Makes me wonder, though, why they didn't just call the property Count instead of Length? Array is the only common collection that has such a property (unless you count string).

[dlev]

@TimS A good question (and one whose answer I don't know.) I would speculate that the reason is because "count" implies some number of items, whereas an array has an unchangeable "length" as soon as it is allocated (regardless of which elements have values.)

[MgSam]

Thanks. I hadn't considered it being implemented explicitly. The reasoning behind making this an explicit implementation breaks down though when you consider LINQ, as Arrays have the Count() extension method like every other enumerable.

[Tim S.]

@dlev: and yet, ReadOnlyCollection<T>'s property is .Count: msdn.microsoft.com/en-us/library/ms132507.aspx, not .Length.

[dlev]

@MgSam Good point. That's actually one of the reasons extension methods should be scoped to apply as narrowly as possible, so that public "interfaces" are polluted as little as possible. Nonetheless, there's nothing to be done about the LINQ issue, whereas explicit implementation was available in the List<T>.Count case.

[Kevin Aenmey]

I think you will get a compile-time failure on foo.M1(); not foo.M2();

[dlev]

@TimS I think that's done because ICollection declares Count, and it would be even more confusing if a type with the word "collection" in it didn't use Count :). There are always trade-offs in making these decisions.

[MgSam]

@dlev I actually prefer how it is for extension methods in that it's visible on any type they apply to. I have trouble believing that hiding public functionality of a type that has not been cast to anything is a good thing. If there's only a single public method on a type, it should be available if it is explicit or not. I think only if there's multiple implementations, implicit and explicit, should the explicit ones be hidden. A good example of this is Clear(). There is no reason for an array not to have a visible Clear() function; its something people often implement themselves.

[dlev]

@MgSam I assume Clear() on a variable of type T[] sets each element to default(T)? Interestingly, there is a public method on Array that clears it: msdn.microsoft.com/en-us/library/system.array.clear.aspx I'm not really sure why the method is static.

[user1703401]

The challenge here is to have a non-generic class, like an array, implement a generic interface type, like IList<>. Your snippet doesn't do that.

[Jon Skeet]

@HansPassant: It's very easy to make a non-generic class implement a generic interface type. Trivial. I don't see any indication that that's what the OP was asking about.

[Jon Skeet]

@JohnSaunders: And again... just a downvote with no useful information.

[Jon Skeet]

That's the declaration for the Array class, which isn't the type of an array. It's the base typefor an array. A single-dimensional array in C# does implement IList<T>. And a non-generic type can certainly implement a generic interface anyway... which works because there are lots of different types - typeof(int[]) != typeof(string[]), so typeof(int[])` implements IList<int>, and typeof(string[]) implements IList<string>.

[Jon Skeet]

I see it's more complicated (just looking at the CLI spec) but I still don't think this is entirely reasonable in terms of the "It can't" part. I'm editing my answer to give more information in a complementary way.

[Jon Skeet]

Now found the directly contradictory part of the CLI spec: "Additionally, a created vector with element type T, implements the interface System.Collections.Generic.IList<U>, where U := T. (§8.7)"

[John Saunders]

@JonSkeet: wnat's so hard? It's not an explicit implementation.

[Jon Skeet]

@JohnSaunders: Actually, I don't believe any of it was inaccurate before. I've expanded it a lot, and explained why the CLR treats arrays oddly - but I believe my answer of explicit interface implementation was pretty correct before. In what way do you disagree? Again, details would be useful (possibly in your own answer, if appropriate).

[Jon Skeet]

Haven't actually downvoted this due to the useful parts around SZArrayHelper - but it is incorrect according to both the C# language specification and the CLI specification around whether or not an array type (not System.Array, but the actual type) implements IList<T>... and it behaves in all ways like explicit interface implementation as far as I can tell.

[Jon Skeet]

@JohnSaunders: I'm still not convinced. Hans has referred to the SSCLI implementation, but also claimed that array types don't even implement IList<T>, despite both language and CLI specifications appearing to the contrary. I dare say the way that the interface implementation works under the covers may be intricate, but that's the case in many situations. Would you also downvote someone saying that System.String is immutable, just because the internal workings are mutable? For all practical purposes - and certainly as far as the C# language is concerned - it is explicit impl.

[user1703401]

Jeez Jon, don't let this answer get to you. People usually find it rewarding to discover a new truth, little point in downvoting it because it is unsettling. Try to reason out the comment in the copied snippet from get_Count() and match it with what the specifications say about instance methods to see the dragon.

[Jon Skeet]

@HansPassant: Please don't assume that I'd downvote something just due to it being unsettling. The fact remains that both your reasoning via Array (which as you show, is an abstract class, so can't possibly be the actual type of an array object) and the conclusion (that it doesn't implement IList<T>) are incorrect IMO. The way in which it implements IList<T> is unusual and interesting, I'll agree - but that's purely an implementation detail. To claim that T[] doesn't implement IList<T> is misleading IMO. It goes against the spec and all observed behaviour.

[user1703401]

Well, sure you think it is incorrect. You cannot make it jive with what you read in the specs. Please feel free to see it your way, but you'll never come up with a good explanation why GetInterfaceMap() fails. "Something funky" is not much of an insight. I'm wearing implementation glasses: of course it fails, it is quack-like-a-duck typing, a concrete array type doesn't actually implement ICollection<>. Nothing funky about it. Let's keep it here, we'll never agree.

[Jon Skeet]

What about at least removing the spurious logic that claims arrays can't implement IList<T> because Array doesn't? That logic is a large part of what I'm disagreeing with. Beyond that, I think we'd have to agree on a definition of what it means for a type to implement an interface: to my mind, array types display all the observable features of types which implement IList<T>, other than GetInterfaceMapping. Again, how that is achieved is of less importance to me, just like I'm fine with saying that System.String is immutable, even though the implementation details are different.

[supercat]

When applied to an array of a derived type, the returned list won't be exhaustive, since a SiameseCat() will implement IList<Animal> even though the latter type is neither listed among the supported interfaces, nor implied by them (although IList<SiameseCat> implies IEnumerable<Animal>, IList<SiameseCat> does not imply IList<Animal>).

[supercat]

Every heap object whose type derives from ValueType is a fully legitimate derivative of Object. The "illusion" associated with value types goes the other way--with the fact that a storage location of a type descended from Object (other than System.Enum) will hold neither an Object, nor a reference to one.

[RBT]

Hey Jon! Honestly I couldn't understand a lot either from yours or Hans's answer. It seems like a very complicated topic. But from a layman's standpoint will it be right to say that - Arrays simply do explicit implementation of interfaces like IList and ICollection. It is not just about Count property mentioned by OP but other contracts as well present in IList interface e.g. Add,Remove,etc. I can always do like this in code - int[] myArr = new int[20];((IList)myArr).Add(4); var myCount = ((ICollection)myArr).Count;

[Jon Skeet]

@RBT: Yes, although there's a difference in that using Count is fine - but Add will always throw, as arrays are fixed-size.

[Tobias Knauss]

What about the C++CLI compiler? That one obviously says "I have no idea how to do that!" and issues an error. It needs an explicit cast to IList<T> in order to work.