title: Why may a generic type not use a concrete version of itself?
body: <h3>TL;DR</h3>
  <ul>
  <li>Why may we not use a concrete version of a generic type within its own generic implementation? Since it's a concrete type, I see no issues with &quot;recursive typing&quot;. Is this a design decision? Or a current limitation?</li>
  </ul>
  <hr />
  <p><strong>Background</strong></p>
  <p>When playing around with generics, I stumbled over the following (for me, previously unknown) curiosity:</p>
  <pre><code>struct Foo&lt;T&gt; { let foo: T }
  
  struct Bar&lt;U&gt; {
      let bar: U
  
      func foobar() -&gt; Foo&lt;Bar&gt; {
                     /* ^^^ Bar&lt;U&gt; inferred */
          // no matter of the actual implementation ...
          return Foo(foo: self)
      }
  
      // even without inference help from the implemention
      func nilFoobar() -&gt; Foo&lt;Bar&gt;? { return nil }
  }
  </code></pre>
  <p>Particularly how the return type of <code>foobar()</code> needn't specify the placeholder type of <code>Bar</code> (which in turn is the placeholder for the generic <code>Foo</code> return), as this seems to be inferred as the same placeholder type as <code>Self</code> (concrete <code>U</code> in <code>Self</code>). I.e., as I see it, the above is equivalent to (except for the Option-click description of the <code>foo()</code> method in Xcode)</p>
  <pre><code>struct Foo&lt;T&gt; { let foo: T }
  
  struct Bar&lt;U&gt; {
      let bar: U
  
      func foobar() -&gt; Foo&lt;Bar&lt;U&gt;&gt; {
          return Foo(foo: self)
      }
  
      func nilFoobar() -&gt; Foo&lt;Bar&lt;U&gt;&gt;? { return nil }
  }
  </code></pre>
  <p>Since <code>Bar</code> in the return type of <code>foobar()</code> is inferred<sup>†</sup> as <code>Bar&lt;U&gt;</code>, I realized that this in turn should disallow a generic types using concrete versions of itself (something I've never had or have a reason to do ...). As expected, this theory holds:</p>
  <pre><code>struct Foo&lt;T&gt; { let foo: T }
  
  struct Bar&lt;U&gt; {
      let bar: U
  
      func foobar() -&gt; Foo&lt;Bar&lt;Int&gt;&gt; {
          return Foo(foo: Bar(bar: 1))
                                /* ^ error: 'Int' is not convertible to 'U' */
      }
  
      // concrete version of other generic type naturally allowed
      func fooint() -&gt; Foo&lt;Int&gt; {
          return Foo(foo: 1)
      }
  }
  </code></pre>
  <p><sub>[†] Rather than inferred, perhaps a shortcut for is a better description? Since it compiles even without an actual implementation to fall back to w.r.t. inference.</sub></p>
  <p><strong>Question</strong></p>
  <p>I don't have any use for using concrete versions of <code>Self</code> within a generic type, but with some imagination, I could see this being used in some corner case context. More so, out of a technical viewpoint (and curiosity), I'm interested in why this seems to be disallowed by design.</p>
  <ul>
  <li>Why may we not use a concrete version of a generic type within its own implementation? Since it's a concrete type, I see no issues with &quot;recursive typing&quot;. Is this a design decision? A current limitation?</li>
  </ul>
  <p>I hope this question doesn't fall under opinion-based. Given the open official community of Swift, maybe someone can shed official-connecting light for the reasoning as to why this should be disallowed by design (or is it simply a current &quot;limitation&quot;?).</p>