StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>New answer in the light of Hans's answer</strong></p> <p>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 <em>very hard</em> to give the impression that an array type implements <code>IList<T></code> - 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 <em>isn't</em> <code>System.Array</code> - that's just the <em>base</em> type of the array. If you ask an array type what interfaces it supports, it includes the generic types:</p> <pre><code>foreach (var type in typeof(int[]).GetInterfaces()) { Console.WriteLine(type); } </code></pre> <p>Output:</p> <pre><code>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] </code></pre> <p>For single-dimensional, zero-based arrays, as far as the <em>language</em> is concerned, the array really does implement <code>IList<T></code> too. Section 12.1.2 of the C# specification says so. So whatever the underlying implementation does, the language has to <em>behave</em> as if the type of <code>T[]</code> implements <code>IList<T></code> as with any other interface. From this perspective, the interface <em>is</em> implemented with some of the members being explicitly implemented (such as <code>Count</code>). That's the best explanation at the <em>language</em> level for what's going on.</p> <p>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). <code>T[,]</code> <em>doesn't</em> implement <code>IList<T></code>.</p> <p>From a CLR perspective, something funkier is going on. You can't get the interface mapping for the generic interface types. For example:</p> <pre><code>typeof(int[]).GetInterfaceMap(typeof(ICollection<int>)) </code></pre> <p>Gives an exception of:</p> <pre><code>Unhandled Exception: System.ArgumentException: Interface maps for generic interfaces on arrays cannot be retrived. </code></pre> <p>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 <code>IList<T></code> is <em>not</em> covariant (and can't be safely), array covariance allows this to work:</p> <pre><code>string[] strings = { "a", "b", "c" }; IList<object> objects = strings; </code></pre> <p>... which makes it <em>look</em> like <code>typeof(string[])</code> implements <code>IList<object></code>, when it doesn't really.</p> <p>The CLI spec (ECMA-335) partition 1, section 8.7.1, has this:</p> <blockquote> <p>A signature type T is compatible-with a signature type U if and only if at least one of the following holds</p> </blockquote> <p>...</p> <blockquote> <p>T is a zero-based rank-1 array <code>V[]</code>, and <code>U</code> is <code>IList<W></code>, and V is array-element-compatible-with W.</p> </blockquote> <p>(It doesn't actually mention <code>ICollection<W></code> or <code>IEnumerable<W></code> which I believe is a bug in the spec.)</p> <p>For non-variance, the CLI spec goes along with the language spec directly. From section 8.9.1 of partition 1:</p> <blockquote> <p>Additionally, a created vector with element type T, implements the interface <code>System.Collections.Generic.IList<U></code>, where U := T. (§8.7)</p> </blockquote> <p>(A <em>vector</em> is a single-dimensional array with a zero base.)</p> <p>Now in terms of the <em>implementation details</em>, clearly the CLR is doing some funky mapping to keep the assignment compatibility here: when a <code>string[]</code> is asked for the implementation of <code>ICollection<object>.Count</code>, it can't handle that in <em>quite</em> 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 <em>behaves</em> that way from a language perspective.</p> <p><strong>What about <code>ICollection.Count</code>?</strong></p> <p>So far I've talked about the generic interfaces, but then there's the non-generic <code>ICollection</code> with its <code>Count</code> property. This time we <em>can</em> get the interface mapping, and in fact the interface is implemented directly by <a href="http://msdn.microsoft.com/en-us/library/system.array.aspx" rel="noreferrer"><code>System.Array</code></a>. The documentation for the <a href="http://msdn.microsoft.com/en-us/library/bb357392.aspx" rel="noreferrer"><code>ICollection.Count</code></a> property implementation in <code>Array</code> states that it's implemented with explicit interface implementation.</p> <p>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.</p> <p><strong>Old answer around explicit interface implementation</strong></p> <p>Despite the above, which is more complicated because of the knowledge of arrays, you can still do something with the same <em>visible</em> effects through <a href="http://msdn.microsoft.com/en-us/library/ms173157.aspx" rel="noreferrer">explicit interface implementation</a>.</p> <p>Here's a simple standalone example:</p> <pre><code>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 } } </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload