1.先把词输入对。
范型(paradigm)
泛型(generics)
2.讨论泛型，C 放进来是用来嘲讽用的么。
这还是因为现在 C 有_Generic ，够当作底线了（但是 OP 一点没提）。
手工复制和旧式 C 宏连当作范型的底线都不配，因为和类型系统完全没有交互。
（原文评论区说无关是因为预处理器原因，这是错的，因为 pp phase 也是语言规范钦定的一部分，不应作为是否算是泛型实现的准则。否则 multi-stage programming 之类的就尬了。）
3.不要参考什么强类型弱类型之流只会让概念更加含混的伪劣资料来源。
所谓的强类型对立的就是“无”类型或者单一类型(unityped)。
更原则性上的错误在于这根本不属于类型检查，而是确保存在能被检查的类型的前提。
（
cf.github.com/FrankHB/pl-docs/blob/master/zh-CN/typing-vs-typechecking.md ）
4.装箱本质上和类型系统无关。
把装箱的外延缩小为几种 manifest typing 的语言的应用实例是一个常见理解偏差。
(
cf.stackoverflow.com/a/69991369 ）
利用装箱实现泛型只是用了箱和被装的对象的非同一性；技术上，这里拿来装出来的是不是箱并不重要。
对象布局根本上需要通过 ABI 约定，箱不是描述 ABI 的抽象。
5.类型擦除和装箱无关。（为什么是 ed 不是 ing ？）
没有箱的类型擦除一样可以实现某种意义上的泛型。
6.vtable 不一定是虚“函数”表（就 Java 来说，一般叫虚方法表）。
虚表这里只是用来替代 RTTI ，跟装箱也无关。
7.同上，图中的字典传递跟装箱也无关。
而且跟虚表并列的应该是字典（虽然这个词太滥了），同样是用来实现某种 RTTI 替代品。
文章和目录里倒是正常了一点。
原文评论区有说 Type Erasure/Dictionary ，这个也不确切，更准确地，应该是+。两者都算不上是完整的实现技术。
但是前者是任意 manifest typing 意义上必要的，后者只是针对静态语言静态区分数据和所谓泛型函数的可选优化。
8.文章里说的 type parameter 暗示实现的说法是错的。
type parameter 本来就是 parameteric polymorphism 的核心，没 type parameter 的系统根本不会叫做泛型。
原文的评论区也指出了这一点。
要有区别，就是 typing 意义上的强度，例如类型系统是否允许支持所谓的 non-type parameter （根本地，形式上还是 type ，比如 dependent type ）。
9.文章链接的《透过 Rust 探索系统的本原：泛型》里把泛型函数从参数化类型中独立出来的做法在概念上是错的。
泛型函数的区别无非是类型参数和→这个类型构造器的交互，所以是参数化类型的一部分。
如果类型系统允许一个值同时居留于不带有→和带有→的类型（如类型擦除可以把*→*这个 kind 擦回*），那么单独考虑泛型函数差不多完全就是实现细节。
当然，考虑到带有→的 STLC （λ→）是 lambda cube 往其它类型系统（典型地，System F(λ2)）扩展的原点，基本上会涉及泛型函数的语言都不允许这样做，即便类型擦除有能力实现；所以这点很容易被一般的作者忽视掉。