对于Scala语言来说，类型擦除有哪些优势？

Question

我听说过很多不同的JVM语言，它们仍处于虚拟产品模式，并提出以某种方式实现具体化。我有这样一个烦人的半记忆（或者完全是想象的，不知道哪个）想法，就在某个地方我读到过Scala如何利用JVM的类型擦除来完成一些它无法使用具体化完成的事情。这对我来说并没有太多意义，因为Scala不仅在JVM上实现，在CLR上也有实现，所以如果具体化引起了某种限制，它将会在CLR实现中显示出来（除非CLR上的Scala只是忽略了具体化）。

那么，对于Scala来说，类型擦除有好的一面，还是具体化是完全正确的事情？

- Nathan Hughes

---

如果只有最普及的JVM语言也效仿就好了。 :( - Kirk Woll

除非Scala在CLR上忽略了具体化，否则它会执行。 - soc

Answer 1

请参考 Ola Bini的博客。众所周知，Java 使用站点协变性（use-site covariance），通过在需要协变的地方添加小问号来实现。而Scala采用定义站点协变性（definition-site covariance），由类设计者实现。他说：

“泛型是一种复杂的语言特性。如果将它添加到一个已经具有子类型的现有语言中，这将使其变得更加复杂。这两个特性在一般情况下并不很好地配合，因此在将它们添加到语言时必须非常小心。如果虚拟机只需服务于一种语言，且该语言采用相同的泛型，则将它们添加到虚拟机是简单的。但是，泛型还没有完成。我们还不完全了解如何正确处理它，新的突破正在发生（Scala就是一个很好的例子）。在这一点上，泛型不能被认为是“做得对”的。泛型不仅有一种实现策略、功能和边角案例。”

“所有这些都意味着，如果你想要将反射泛型添加到JVM中，那么你应该非常确定该实现可以包容所有希望在自己版本的泛型中进行创新的静态语言，以及所有希望创建良好实现和与Java库进行良好接口的动态语言。因为如果你添加的反射泛型不符合这些条件，你将扼杀创新，使JVM作为多语言虚拟机更加困难。”

也就是说，如果JVM具有反射泛型，很可能这些反射泛型并不适合我们真正喜欢Scala的特性，我们将被困在某种次优选择中。

- Ken Bloom