泛型类型参数的T，U，V约定来自何处？

Question

Java，C＃和TypeScript（也称为Sun / Hejlsberg语言系列）使用T，U，V等来表示泛型类型参数。表面上是因为T代表＆＃34;类型＆＃34;，U和V跟随字母表中的T。

另一方面，Scala使用A，B，C等等，OCaml和Haskell使用a，b和{ {1}}。

这些惯例来自哪里？是因为函数式语言更接近数学证明，惯例使用c，α和β？

类似，但没有回答我的问题：Where does the C# generics naming convention come from?。

Answer 1

在标准Java SE API中，设计人员通常选择与字体参数的含义/目的相关的单字母标识符：

• Iterator<T> - javadoc其中T表示类型。其他示例包括ListIterator<T>，Iterable<T>，Comparable<T>，Comparator<T>和Class<T>。
• Collection<E> - javadoc其中E表示元素。各种其他集合类和接口使用E。
• Map<K,V> - javadoc其中K表示密钥，V表示值。
• Enum<E> - javadoc其中E表示枚举。

这些倾向于反驳你的断言，即存在一般（广泛的）T，U，V约定，至少对于Java而言。显然，在没有具体指导的情况下，一些个体设计师会采用对T指南的明显扩展（见下面的链接），但这似乎是个人选择的结果。 （并且这些团体可能会认为这不值得讨论。）

（如果您想进行详尽的搜索，请访问每个javadocs索引A-Z页面，并搜索所有出现的＆＃34;＆lt;＆＃34;。）

  

我希望链接到旧讨论/提交/邮件列表，其中首次讨论该约定。

对于Java，我怀疑你会发现这个。讨论和邮件列表将是私有的，当将泛型添加到该语言时，Java源代码仍然关闭，以及上面的所有示例。

@Lew Bloch在Java 8中添加到Java SE的API中找到了T，U，V的一些示例（见下文），作为流支持的一部分。我断言这不是一般模式，并且大量已有的类反驳了它。

一般模式或惯例的其他负面证据：

• http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-type-variables，但未提及U和V。
• http://docs.oracle.com/javase/tutorial/java/generics/types.html建议使用S，U和V作为第二，第三和第四类型参数。 （不是U，V，W ...）

最后，JLS（JLS 6.1）建议：

  

类型变量名称应该是精简的（如果可能的话，单个字符）但是令人回味，并且不应包括小写字母。这样可以很容易地将类型参数与普通类和接口区分开来。

     

容器类型应使用名称E作为其元素类型。地图应使用K作为其键的类型，V作为其值的类型。名称X应该用于任意异常类型。我们使用T作为类型，只要没有更具体的类型来区分它。 （通用方法通常就是这种情况。）

     

如果有多个类型参数表示任意类型，应使用字母表中与T相邻的字母，例如S。或者，它可以使用数字下标（例如T1，T2）来区分不同的类型变量。在这种情况下，所有具有相同前缀的变量都应该下标。

简而言之，JLS中未明确提及U和V，但其他替代方案是。