Typescript（真的）是否遵循泛型中参数化类型（T、U、V、W）的命名约定？

Question

我不确定在 TS 中我们是否遵循 C++/Java 或许多其他语言 (T,U,V,W) 等参数化类型的命名约定。

我多次看到 TS 中参数化类型约定的混合使用。 比如在release notes of TS 2.8：

type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

为什么是R 而不是U？

那么，在下一个例子中：

type Unpacked<T> = T extends (infer U)[]
  ? U
  : T extends (...args: any[]) => infer U
  ? U
  : T extends Promise<infer U>
  ? U
  : T;

为什么是U 而不是R？

另一个例子，在上面代码的同一个代码块中：

type T0 = Unpacked<string>; // string
type T1 = Unpacked<string[]>; // string
type T2 = Unpacked<() => string>; // string
type T3 = Unpacked<Promise<string>>; // string
type T4 = Unpacked<Promise<string>[]>; // Promise<string>
type T5 = Unpacked<Unpacked<Promise<string>[]>>; // string

但在TS源代码中：

// We represent tuple types as type references to synthesized generic interface types created by
// this function. The types are of the form:
//
//   interface Tuple<T0, T1, T2, ...> extends Array<T0 | T1 | T2 | ...> { 0: T0, 1: T1, 2: T2, ... }

以上问题只是说明问题的示例，您无需回答。 我可以添加一些其他示例，其中 U 有时被视为返回类型，有时只是第二种类型。

我真正的问题是：我们（真的）关注Java Generic Types convention 的 TS Generics 吗？ 如果不是，TS 对泛型遵循什么样的约定？ TS 中同时存在多少种不同的类型约定（除了类型名称的明显 PascalCase 和类型属性/方法的 camelCase）？

Answer 1

（主要来自 cmets）

我能想到的最接近的回答这个不仅仅是我的意见是指向一些描述“TypeScript 类型参数命名约定”是什么的文档，并将其与您链接的Java Generics tutorial document 进行比较。

如果是这样，TypeScript 设计团队对此的官方立场似乎是“我们不打算将任何此类约定强加给其他人”，或者“TS 中没有规范的命名约定”。见microsoft/TypeScript#6168 和microsoft/TypeScript#878，特别是this comment：

[I]一般来说，我们对为人们决定风格上的东西不感兴趣。说 TS 有一种认可的样式违背了我们的理念，即我们在这里为 JS 提供类型，无论您如何编写它（当然是在合理的参数范围内 ?）。

还有ESLint's naming-convention rule 和TSLint's naming-convention rule，这使得可以在经过 linter 检查的代码库中强制执行类型参数命名约定，但默认情况下似乎不这样做 /em>。因此，似乎没有任何约定足够正式，可以默认强制执行。

---

为了比较起见，让我们看一下您链接的 Java 泛型教程文档中的相关部分：

类型参数命名约定

按照惯例，类型参数名称是单个大写字母。这与您已经知道的变量命名约定形成鲜明对比，并且有充分的理由：如果没有这种约定，就很难区分类型变量和普通类或接口名称。

最常用的类型参数名称有：

• E - 元素（Java 集合框架广泛使用）
• K - 键
• N - 编号
• T - 类型
• V - 值
• S、U、V 等 - 第 2、第 3、第 4 类

您将在整个 Java SE API 和本课的其余部分中看到这些名称。

请注意，上面列举的列表被描述为“最常用的类型参数名称”，而不是“唯一允许的类型参数名称”；这是一个列表 示例，因此 descriptive 而不是 prescriptive。

关于选择“单个，大写字母”的部分更接近处方：大写字母倾向于区分类型名称和变量名称和单字符类型名称倾向于区分类型参数和特定类型，如类或接口。但我有同样的感觉，这与其说是上层的法令，不如说是对普遍做法的观察。

---

所以我们大概可以停在那里说“TypeScript 或 Java 中没有官方或规范的类型参数命名约定，任何非官方的此类约定都是见仁见智的问题。”

但为了尝试列出我认为 TypeScript 中的非官方约定实际上是，我会继续。请记住，这是我的意见，人们可能会不同意。

---

我想说，上面列出的 Java 命名约定与我认为的 TypeScript 泛型类型参数的实际命名约定非常接近：使用单个大写字符，或者对应于它们的第一个字母表示，如：

• T 代表“类型”，最通用也是最常用的类型参数名称；
• K 表示“key”，或P 表示“property”，这两者都倾向于受到PropertyKey 或keyof T 或keyof SomeInterface 或keyof SomeClass 的约束；
• V 表示“值”，最常与K 表示“键”成对使用；
• A for "arguments" and R for "return"，分别对应函数签名的其余参数列表和返回类型，如(...args: A) => R；
• N 用于“数字”，S 用于“字符串”，B 用于“布尔值”，用于受基元约束的类型参数；

或一些相关类型的序列，例如：

• T、U、V、W 等，从 T 开始表示“类型”，然后在需要更多类型时遍历字母表，请记住，你只能得到几个这个方式；
• A、B、C、D 等，从字母表的开头开始，当您希望使用一大堆类型参数并且您还没有将类型参数用于其他用途时。

这样的约定不是绝对的，并且会在必要时进行弯曲以避免歧义或其他混淆。如果您需要的类型参数多于上面没有名称冲突的情况，则可能需要在名称中添加一个字符：

• T0、T1、T2、T3等，附加数字得到相关类型的序列；
• KT、KU、KV：分别为 T、U 和 V 的“键”添加前缀 K；

这与我认为的传统方式相去甚远，但仍然足够普遍，可以编写短的 UpperCamelCase 名称来更好地描述类型所代表的内容，缺点是它们可能会开始混淆特定类型而不是类型参数：

• Key, Val, Prop, Arg, Ret, Type, This

以下是非常规的（记住，我的意见在这里！）应该避免，除非有一些压倒性的情有可原的理由这样做：

• 类似于接口或类名的长名称，例如InputType 或Properties；
• 在较长的类型名称（如 TNotRecommended）上添加大写 T 前缀；
• 以小写字母开头的名称，例如 t 或 u 或 myType；