Allow implementing classes to use themselves as types
<p>I am just wandering if the following is possible in C#.</p>

<p>Let's say I have a List-like interface that mandates the operation <code>reverse</code>. I.e.:</p>

<pre><code>public interface ReversableList&lt;T&gt; {
      // Return a copy of this list but reversed
      ReversableList&lt;T&gt; Reverse();

      // We still need to return the contained type sometimes
      T Get(int index)
}
</code></pre>

<p>However, now when I go and implement that interface:</p>

<pre><code>public class ListImplementation&lt;T&gt; : ReversableList&lt;T&gt; 
      ReversableList&lt;T&gt; Reverse();   
}
</code></pre>

<p>I am still forced to use the interface <code>ReversableList</code>. So even if the user were to instantiate my <code>ListImplementation</code> directly, they are still forced to deal with <code>ReversableList</code> when calling the <code>Reverse</code> method:</p>

<pre><code>var concreteList = new ListImplementation&lt;String&gt;();
ReversableList&lt;T&gt; reversed = concreteList.Reverse(); 
</code></pre>

<p>whereas what I had in mind was that <code>Reverse()</code> of the <code>ListImplementation</code> will be another <code>ListImplementation</code>, like so:</p>

<pre><code>var concreteList = new ListImplementation&lt;String&gt;();
ListImplementation&lt;String&gt; reversed = concreteList.Reverse();
</code></pre>

<p>while still implementing a generic enough interface.</p>

<p><em>If this is confusing, let me know and I will clarify/add any necessary details or corrections. Thank you!</em></p>

<h2>Source of interest</h2>

<p><em>What follows is the explanation for why this is interesting to me.</em></p>

<p>I followed the function called <code>reversed</code> in the <a href="http://www.decodified.com/scala/collections-api.xml" rel="nofollow">scala's collections</a> from the <code>List</code> (which is a concrete type) through all the interfaces (traits) that it inherits.</p>

<p>What I found is very curious.</p>

<p>The original <code>reverse</code> method is defined abstractly on the <a href="http://www.scala-lang.org/api/current/scala/collection/GenSeqLike.html" rel="nofollow"><code>GenSeqLike</code> trait</a>.</p>

<pre><code>trait GenSeqLike[+A, +Repr] ...
    def reverse: Repr   // &lt;--- NO BODY, means abstract
</code></pre>

<p><br/>Then, it is defined <em>concretely</em> in a <a href="http://www.scala-lang.org/api/current/scala/collection/SeqLike.html" rel="nofollow">trait SeqLike</a> that extends <code>GenSeqLike</code> trait:</p>

<pre><code>trait SeqLike[+A, +Repr] extends GenSeqLike[A, Repr]
    def reverse: Repr
        //iterates through this seqence
        // and reverses 
        for (x &lt;- this)
           //...etc
</code></pre>

<p><br/>Then, what is interesting, is that the next two traits:</p>

<pre><code>trait Seq[+A] extends SeqLike[A, Seq[A]]   //&lt;-- NOTE here is the type for "Repr"
     //no mention of reverse

trait LinearSeq[+A] extends Seq[A] with SeqLike[A, Seq[A]] //&lt;-- NOTE type again
    // no mention of reverse
</code></pre>

<p>both get a "free" version of the <code>reverse</code> function, but both of them work in terms of their respective "interfaces" (traits). So <code>reverse</code> on <code>Seq</code> returns a <code>Seq</code>.</p>

<p>Finally, the <code>List</code> concrete class implements the <code>LinearSeq</code> trait and redefines the <code>reverse</code> method (for efficiency purposes I assume). </p>

<pre><code>sealed abstract class List[+A] extends LinearSeq[A]
                                 with LinearSeqOptimized[A, List[A]] 

      override def reverse: List[A] = {
          //faster impl without foreach iteration
          ...
      }
</code></pre>

<p>where the <code>LinearSeqOptimized</code> is simply another "chain" of traits that goes all the way up to <code>SeqLike[A, Repr]</code>.</p>

<p>So you can see, how a generic "interface" was used to specify some "behavior", how an intermediate "interface" provided some kind of "default" implementation, and how all the sub-"interfaces" and subtypes all reaped the benefit of that implementation while preserving the return types to be of their "own" types. Phew. Confusing, I know!</p>
