高级类型(Higher-kinded Types)——并非完整的提案
高级类型(HKTs)在语言的大部分存在时间里都是被广泛讨论和期望的功能，多年来也提出了许多用例，但到目前为止，我所知的还没有具体的提案。
其中一个困难之处在于，高级类型通常在具有截然不同的(即名义上的)类型系统的编程语言中定义。因此，将它们简单地移植到该语言中实际上没有意义——相反，它们需要重新构想并重新表述以适应该语言的其他部分。
以下是一个这样的重新构想。
这个提案引入了两个新的类型系统构造。

• 容器类型:这些是高级类型。它们不可分配(没有示例)。它们将类型声明转换为TypeScript可以推理的结构。
• Kinds: HKT中的K。Kinds是高阶类型，其示例都是其他类型。它们用于量化一系列容器类型的家族。使用type type声明一个kind别名。

第一部分：容器类型

一个容器类型是一个包含类型成员和无值成员的类型。下面是一个容器类型的示例：

// A container type that has two type members.
type Container = {
    type A = number
    type B = string
}

容器类型不是有人居住的——它们没有示例，而像let a: Container这样的类型注解等同于let a: never,尽管在实践中这实际上是非法的。我们也可以说一个容器类型是非分配的。
容器类型确实有一个类型级别的结构。这种结构可以产生可分配的类型。
下面是一个这样的别名从一个容器类型产生可分配的类型的示例：

// You've seen this before, haven't you?
type Example = Container.A

定义了它们之后，我们实际上可以在语言中找到容器类型。让我们看一下常见的命名空间。

// Plot twist! 
// Namespaces have been the key to HKTs all along.
namespace Container {
    type Example1 = number
    type Example2 = string
    export const value = 5 as const;
}

上面的声明创建了几个不同的实体：

1. 值绑定Container,其中有值成员如Container.value。
2. 类型typeof Container,它等同于{value: 5}。
   但是类型定义Example1和Example2实际上是在第三个实体中，一个隐藏的容器类型也被称为Container。

容器类型的成员

容器类型可以有泛型成员以及常规成员。这与对象类型可以有值成员和函数成员类似。此外，我们知道这一点，因为命名空间也可以拥有这些东西。

将泛型作为带有泛型调用签名的容器类型的泛型类型

普通类型可以定义一个调用签名。类似地，容器类型可以定义一个泛型调用签名：

type Example = {
    type <T> = number
}

事实上，每个泛型类型实际上都是一个带有此类签名的容器类型。

容器类型还可以嵌入其他容器类型，创建嵌套的类型结构。

type Nest = {
    type Parent = {
        type Leaf = string
    }
}

容器类型的子类型关系

TypeScript通过结构性方式确定子类型关系，对于容器类型也是如此。然而，容器类型的结构是其他类型的嵌套方式，这会影响基于它可以产生的可分配类型的整个程序。
在我们可以抽象出容器类型之前，我们需要为它们定义一个子类型关系⊆。子类型关系决定了两个容器类型A、B在结构上是等价的—— A ≡ B。这种关系的定义将改变这些类型的“结构”在上下文中的含义。
我们将定义一个非常严格的子类型关系，比普通类型的赋值关系严格得多。也就是说：
对于一个容器类型Sub要成为另一个容器类型的子类型—— Super、 Sub ⊆ Super、 Sub必须当受到各种操作时产生与Super相同的类型。
让我们形式化一下。为了做到这一点，我们需要定义一种称为*type formula的东西。

type formula: 一个元语言构造。一个type formula是一个涉及替换令牌φ的表达式。type formula由以下组成：

1. φ
2. 访问成员类型， φ.Member
3. 用φ<T₁, …, Tₙ>示例化一个类型构造器
   我们将编写这样一个type formula:

F{φ} ⇒ φ.Something<number>.A

这里还有一些更多的例子。

F{φ} ⇒ φ.One.Two.Three<number>
F{φ} ⇒ φ<string>

现在来定义我们的子类型关系：
对于两个容器类型Sub、Super、如果对于所有使F{φ}可分配的type formula F{Super},那么对于所有type formula F{Sub} ≡ F{Super}也是如此。
注意我们将最终测试委托给现有的赋值关系，以确保没有无限递归。
我们定义的type formula告诉我们一个容器类型的结构包括：

1. 包含的类型的名称。
2. 对于泛型类型：
3. 泛型类型的参数数量。
4. 对泛型类型的参数施加的约束必须兼容，即如果 Super<X₁, …, Xₙ> 是有效的，那么 x30n30 也必须是有效的。
   让我们来看一些具体的示例。

可分配类型是不变的

{ type A = "a" } ⊈ { type A = string }

可分配类型必须是不变的。

部分结构意味着超类型

{ type A = "a", type B = "b" } ⊆ { type A = "a" }

泛型签名很重要

{ type F<T> = number } ⊈ { type F = number }
{ type F<S> = number } ⊆ { type F<T> = number }

类型参数约束必须兼容

{ type F<T> = T } ⊆ { type F<T extends number> = T }

第二部分：种类(Kinds)

种类是类型的种类，所有普通类型都是其示例。所有非容器类型都有种类 * ,而容器类型则有描述其复杂类型结构的种类。为种类定义别名使用 type type ,其定义使用双大括号 {{}} 。以下是一个示例：

// These things are complicated. Take it from me
type type SomeKind = {{
    type Scalar:*
    type KindBased:OtherKind
    type Constrained extends string
    type Fixed = number
}}

种类将类型变量定义为其成员。每个类型变量都与一个约束一起定义，该约束可以引用其他任何变量。可能有几种约束：

1. 一种种类注解，如在 type KindBased: OtherKind 中，类似于类型注解。这限制了类型变量只能是给定种类的示例。
2. 一种带有种类 * 的种类注解，如在 type Scalar:* 中，它将类型变量限制为非容器(常规)类型。
3. 一种子类型约束，如 type Constrained extends string 。
4. 一个等式约束。这使类型变量固定。
   一个种类的示例是一个满足其成员上所有约束的容器类型。没有特殊的类型信息在别名本身中传递——那部分只是将 kind表达式 绑定到名称。无论您使用对别名的引用还是表达式，对于类型检查的目的都无关紧要。它可能会影响推断，但这是另一回事。
   与其他语言构造一样，您可以嵌套种类表达式。
   种类还可以定义泛型类型成员。这些被转换为使用种类注解的非泛型容器类型。例如，以下是等价的：

type type A = {{
    type F<T> extends number
}}

type type B = {{
    type F: {{
        type <T> extends number
    }}
}}

种类基本上是具有个体示例的超级对象类型，个体示例都是容器类型。一个种类可以有许多可能的示例，可以在需要时轻松构建它们。想象一下一个充满类型的物体。
在对象类型中，每个键都用类型注解约束。在种类中，每个键都可以是更高级的类型(即容器类型)或常规类型(如 string )。我们只需要相应地约束每个成员即可。
子类型约束允许使用常规类型(如 string )约束，而种类约束用于包含泛型类型的容器成员，包括泛型类型。 = 约束主要适用于具有种类 * 的类型。该约束的一个用途是创建辅助类型变量。您甚至可以将其前缀为 _ 并假装它是私有的。

type type WeirdStuff = {{
	type _Something = Blah | string
	type Blah = number
}}

种类不能有自己的类型参数本身。事情已经够糟糕了，不必再处理那个。

示例-of vs subtype-of

重要的是不要把定义在容器类型上的两个关系混淆——容器类型的子类型关系 A extends B 和种类注解 A: K 。
这是因为容器类型既是自身又是其他类型的示例(即种类)。两者之间存在关系——具体来说，如果 B: K 且 A ⊆ B 则 A: K 。

平凡的种类

我们事先知道的一些种类被称为平凡种类。

1. 我们已经提到过的 *
2. 又出现了一次 xm55n1x 。作为没有示例的类型，它就像一个种类一样自在。毕竟只有一个空集之后还有什么呢？
3. 这个种类描述了一个空容器类型。它没有用处。

不适宜居住的种类

你可以很容易地定义自相矛盾的种类。
这个种类 不适宜居住 –它没有示例。像 xm57n1x 这样的存在等同于 xm58n1x 。然而，一般问题 xm5e0f1x 是不可行的，所以语言无法检测到这样的东西。
你也可以创建描述包含自身的类型的种类。

语法位置

一个种类注解看起来就像一个类型注解，除了操作数之外。这些总是一个 类型 和一个 种类 。种类注解应用于以下情况：

1. 类型参数声明。
2. 其他种类的其他类型的类型成员。
3. 对于非泛型容器类型的非泛型容器类型的类型别名声明。在这种情况下，注解确保正在定义的类型符合给定的种类。
   类型变量也可以在它们的约束中引用自身。这里它被用来实现一个在不可变集合中常见的模式：

type type Imm = {{
	type Seq<T> extends {
		push(x: T): Seq<T>
		pop(): Seq<T>
		readonly length: number
	}
}}

作为一个附注，这种引用可能在定义泛型调用签名时是不可能的：

type type Seq = {{
	type <T> extends {
		push(x: T): ?
	}
}}

有几种解决这种情况的方法。第一种方法就是直接禁止它。如果你想写这样的类型，你必须这样做：

type type Seq = {{
	type Instance<T> extends {
		push(x: T): Instance<T>
	}
	type <T> = Instance<T>
}}

虽然这样很别扭。另一种选择是使用类似 <T> 或 This<T> 的东西：

type type Seq = {{
	type <T> extends {
		push(x: T): <T>
	}
}}

我最喜欢的方法是允许使用名称 Seq 。当它出现在类型的位置而不是种类的位置时，它将被视为与 this 类似的自我引用。

type type Seq = {
	type <T> extends {
		push(x: T): Seq<T>
	}
}

我认为这将使通用种类成为定局——如果允许这种语法，它们将会太令人困惑了。
在其他情况下，我们有一个明确标注的符号可以作为自我引用使用，比如在这个函数中：

declare function example<Seq: {{ type <T> extends { push(x: T): Seq<T> }}}>()

类型检查

假设我们有一个带有种类约束的类型参数的函数：

function test<T: K>(x: T.SomeType<string>): true

并且我们有一个调用，如下所示：

test<{
    type SomeType<T> = boolean
}>(thing)

确定这个调用是否合法主要涉及以下几个阶段：

1. 首先，确定指定的容器类型是否是种类 K 的示例。
2. 计算所有类型表达式，用容器类型替换 T 。
3. 对(2)计算出的 thing 和 x 类型的标准可分配性检查。
   所有这些都是可行的，即使第1步对于复杂的种类来说可能会变得计算量很大。

类型推断

假设我们没有显式地指定上面的 test 函数的类型参数，而是直接调用它：

test(thing)

编译器必须尝试构造一个满足 K 并允许函数被调用的容器类型。这基本上相当于解决两个困难的问题：

1. 找到种类为 K 的示例。
2. 在这些示例中，找到一个使得 thing 可以分配给 x 的示例。
   这两个问题对于非平凡的种类来说都是无法解决的，尤其是因为在 TypeScript 中，可分配性已经是一个困难的问题。然而，仍然有一些策略可以解决这个问题。
3. 在调用本身或其上下文中收集现有的类型信息。
4. 在最简单的情况中，已知 thing 的类型可能已经被编译器用容器类型表示出来，用户可以通过确保参数具有精心选择的类型来利用这一点。
   另一个解决方案涉及到尝试在调用本身的上下文中找到 K 的示例，使用各种隐式系统。
   如果有任何值输入被注解为在 K (即 type Something = Sibling<number> )中固定的类型，我们可以使用它们来解析其他类型。
   另一种方法是：以部分容器类型的形式提供直接的类型提示。
   假设我们有以下内容：

type type Example = {{
    type Num extends number
    type Array = Num[]   
}}

function test<T: Example>(arr: T.Array): T.Num

虽然当我们调用该函数时可以坚持使用完整的容器类型，但实际上只需提供 Example.Num 类型的类型值就足够了，因为编译器可以弄清楚其余的部分。
x