IMO, the only buggy thing here is that compiler does not complain about an obvious (for humans) memory corruption.<div><br></div><div>Have you heard about &quot;fruits-apples-oranges&quot; problem with covariance? I first learned it from C++, but it holds in pretty much all languages.</div><div>Consider the following type hierarchy:</div><div><br></div><div>class Fruit {</div><div>    func tell() { print(&quot;I&#39;m a Fruit!&quot;) }</div><div>}</div><div>class Apple : Fruit {</div><div>    override func tell() { print(&quot;I&#39;m an Apple!&quot;) }</div><div>}</div><div>class Orange : Fruit {</div><div>    override func tell() { print(&quot;I&#39;m an Orange!&quot;) }</div><div>}</div><br><div>Now imagine that covariance in generics was allowed. I will also use generic notation for arrays here.</div><div><br></div>var apples: Array&lt;Apple&gt; = []<div>apples.append(Apple())</div><div><br></div><div>var fruits: Array&lt;Fruit&gt; = apples   // can we allow this?</div><div><br></div><div>fruits.append(Orange())</div>apples[0].tell()   //=&gt; I&#39;m an Orange!<div><br></div><div>We obviously don&#39;t want this to happen.</div><div>So we decide to automatically create an empty Array&lt;Fruit&gt; and call append() with all casted elements of the initial array whenever arrays are casted:</div><div><br></div><div>var fruits: Array&lt;Fruit&gt; = copyThatArray(apples) as Array&lt;Fruit&gt;</div><div><br></div><div>Now people will come and ask, why can&#39;t I do the same with Set&lt;Fruit&gt;? With Box&lt;Fruit&gt; from that library? But everything works on Array&lt;Fruit&gt;! Why??</div><div><br></div><div>And so I end my story with conclusion that we should not allow covariant generics in any form.</div>