为什么 Kotlin 中的 reified 关键字，是不是标记 function 内联就足够了？

Question

在 Kotlin 中，考虑到 'reified' 关键字只能用于内联函数的泛型类型参数，为什么还有 reified 关键字呢？ 为什么 Kotlin 编译器（至少在将来）不能自动将内联函数的所有泛型类型参数视为具体化？

我看到人们在看到这个“具体化”的词时会感到恐慌，并要求我不要让代码变得复杂。 因此问题。

Answer 1

实体化类型参数也需要在它们中传递的类型 arguments 也被实体化。 有时这是一个不可能的要求（例如，class 参数不能被具体化），因此默认情况下将内联函数的所有参数都具体化将使得在现在只能调用具有具体类型的函数的情况下无法调用所有内联函数参数：

inline fun<T> genericFun(x: T)  {}
inline fun<reified T> reifiedGenericFun(x: T)  {}

class SimpleGenericClass<T>() {
    fun f(x: T) {
        genericFun<T>(x)        //compiles fine
        reifiedGenericFun<T>(x) //compilation error
    }
}

Answer 2

正如@Михаил reified的回答所表明的那样，被具体化的类型非常有限，因此语言要求您明确明确应该具体化哪些类型是至关重要的。 具体化要求在编译时知道类型，因此具有具体化类型的函数只能从该类型不是非具体化泛型类型的函数中调用。

那么，有人可能会争辩说，如果T::class恰好在这个内联 function 中使用，则假设它已被具体化，否则将其视为未具体化。 但这意味着您的有效 function 签名可以通过更改 function 的内容而不更改其声明来更改。 这将很容易意外更改 function 签名，这是未来灾难的根源。

Kotlin 在这类问题上的设计理念是保守的，需要明确的声明。 这与功能接口必须用fun关键字显式标记的原因相同，即使它们当前只有一个抽象 function，并且类/函数默认情况下是最终的。

Answer 3

接受@Михаил Нафталь 的回答（第一个提供并进一步更新），同时也热烈感谢@Tenfour04。 只是想根据我对所提供答案的理解添加一个（希望如此）更简化的答案，这基本上仍然是正确的：

• “可具体化类型”的实际（但可能不完整）定义是，如果类型类似于List<T> ，我们可以从中评估T::class.java 。 这种可具体化的类型可能没有对其进行类型擦除，这是 java 编译器对类型参数进行的操作，以减少编译二进制文件的大小。 目前看来，在某些情况下，传统的 java 编译器等正在执行类型擦除，而 kotlin 尚未提供自定义方法（即在某些情况下阻止它）。
• 不幸的是，仅从表达式List<T>无法判断该类型是否可具体化。 好像可以为开发人员添加一个关键字来明确地看到这一点，例如： List<nonerased T>和List<erased T> 。 但目前，编译器会根据 T 的定义位置/方式检测到这一点，否则语言可能会变得过于冗长。
• 在非内联函数中，所有泛型类型参数变为不可具体化（擦除），这可能是由于编译时 jvm 类型擦除，与 java 编译器的通常（或目前技术上尚未解决）行为一致。
• 然而，在内联函数中，例如inline fun <T> f1(list: List<T>){...} ，有一个选项可以将类型声明为reified T （这使它成为inline fun <reified T> f1(list: List<T>){...} )，这意味着它将只接受List<nonerased T>类型的参数（具有与它们关联的这个不可见的 'nonerased' 关键字），否则它将给出编译错误。 然后它不会对 T 进行类型擦除。由于此编译时检查，用户现在可以继续使用T::class.java内联 ZC1C425268E68385D1AB5074C1Z，因为他们不会在 T 保证运行时得到错误被erased T ，所以找不到T::class.java 。
• 没有可见的“reified”关键字的内联 function 将表现得像非内联 function 并照常进行类型擦除。