我不确定在TS中我们是否遵循C++/Java或许多其他语言(T,U,V,W
)的参数化类型命名约定。
我在TS中看到了许多次参数化类型约定的混合使用。例如,在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使用了哪些约定来处理泛型? 除了类型名称的 PascalCase 和类型属性/方法的 camelCase 之外,TS还存在多少种不同的类型约定?
K
表示键,P
表示属性,R
表示返回等),或者一些相关类型的序列,如T
、U
、V
或A
、B
、C
。虽然我不确定您的问题是否有明确的答案...但是这样的约定有点像有机/众包的,而不是从高处颁布的。 - jcalzT
,U
,V
来符合多类型泛型的类型参数命名约定。在TS中,我可以随机和可互换地使用T
,U
,V
或A
,B
,C
或X
,Y
,Z
或T0
,T1
,T2
。 因此,我认为可以安全地说,这可能起源于C++ / Java,但它不那么严格。 - GBra 4.669