&gt; Yes, but my question is: even if you use erasure, what are you going to do at the call site? Won&#x27;t you need to state a concrete size there?<p>No, Idris doesn&#x27;t actually care what &quot;n&quot; and &quot;m&quot; are (concretely)... it just knows that if you happen to have a (Vec n a) and (Vec m a) lying arond, then you&#x27;ll get a (Vec (n+m) a) out.<p>&gt; For usual generic types, erasure and code generation are equivalent in what they can do, because at some point you will specialize to concrete types.<p>I&#x27;m not sure I fully understand what you mean, but I think this is slightly wrong... You can think of the fully erased (Vec n a) representation as (n, void-star) in C-style or Array&lt;Object&gt; in JVM style. Note that &quot;a&quot; doesn&#x27;t actually appear. So the type is actually never needed at runtime -- all functions which have (Vec n a) as a parameter will just assume that it has been (statically) proven[1] that the pointed-to-array has the correct size. Because of parametricity, functions will not be allowed to actually access any &#x27;a&#x27; values directly. So it all works out.<p>Here&#x27;s another comment of mine that goes a bit deeper into the interplay between static proof and runtime checks: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10302863" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10302863</a><p>Key being: You either need to <i>prove statically</i> or you need to <i>prove statically that you&#x27;ve checked at runtime</i>.<p>HTH.<p>[1] This is valid because call sites <i>must</i> provide such a proof (statically).