使用接口属性作为输入的过程类型评估

Question

我以为我知道为什么以下代码无法编译（ 操场）：

type Type = [unknown] & { type: unknown };

interface $Zeros extends Type {
//        ~~~~~~
// Type instantiation is excessively deep...
    type: Zeros<this[0]>
}

type Zeros<N, R extends unknown[] = []> =
    N extends R['length'] ? R : Zeros<N, [0, ...R]>;

问题应该是this[0]是unknown ，所以 TS 试图扩展Zeros<unknown>并且由于我在Zeros中表达条件的方式，它无限期地重复出现。

这是我的假设，因为翻转条件化解了它（ 游乐场）：

// no error with this implementation
type Zeros<N, R extends unknown[] = []> =
    R['length'] extends N ? R : Zeros<N, [0, ...R]>;

但是，当我将Type的实现替换为以下一个时，我不会再收到此错误：

type Type = { 0: unknown, type: unknown }

我什至可以毫无问题地直接查询值：

type GetZeros = ($Zeros & [3])['type'];

但是，如果我在一个类型中提取这个逻辑，那么它就不会再编译（并且解决方法，翻转Zeros中的条件，是相同的）：

type apply<$T extends Type, Args> = ($T & Args)['type'];

type applyZeros = apply<$Zeros, [3]>;
//                ~~~~~~~~~~~~~~~~~~
// Type instantiation is excessively deep...

（ 上述设置的游乐场）

我对最后一个片段的行为感到惊讶：我希望this[0]是3 ，所以Zeros应该用3和N extends R['length']应该是3 extends R['length'] ，所以不应该有无限递归......

显然，在这个例子中，我的心理 model 在两个不同的地方让我失望了。 我需要一些见识。 到底发生了什么？

添加一些上下文

以上是我在图书馆试验过的 2 种设计的简化版本。 { 0: unknown, type: unknown }实现有很多优点，也是我目前使用的，但我更喜欢[unknown] & { type: unknown }的行为，因为它可以帮助用户解决这种错误更容易，也更快地找到错误的原因。

在库的正常使用过程中，即使没有应用“参数”， $Zeros['type']也应该被其他类型查询（以检查它是否可以组合），所以重要的是this[0]是unknown的（或某种类型约束），无限递归或无用/退化返回类型等潜在问题由实现者处理。

Answer 1

好的，下面是一个解释性的 model，它不是正典，但对我来说已经足够好了。 我很乐意被反驳。

Type为元组时的过早求值

在下面的代码中，不评估接口$Zeros中的type字段

type Type = { 0: unknown, type: unknown }

interface $Zeros extends Type {
    type: Zeros<this[0]>
}

然而，它通过这个单一的变化得到评估：

type Type = { [x: number]: unknown, 0: unknown, type: unknown }

交集类型[unknown] & { type: unknown }导致添加索引签名，如下面的代码所示：

type Type = Compute<[unknown] & { type: unknown }>
type Compute<T> = { [K in keyof T]: T[K] };

基本原理是，当接口包含索引签名时，类型检查器无法假设 object 上存在的属性，因此在$Zeros的情况下，无法确定字段0是否存在或者它的类型是什么，即使键0明确存在于此接口扩展的Type的定义中。 因此，TS 必须评估type字段以确保其格式正确。

尝试证明这一点的一种方法是删除具有实用程序类型的索引签名

type Type = RemoveIndex<Compute<[unknown] & { type: unknown }>>
type Compute<T> = { [K in keyof T]: T[K] };
type RemoveIndex<T> = {
  [ K in keyof T as string extends K ? never : number extends K ? never : K ] : T[K]
};

然后需要稍微更改$Zeros的定义，因为没有索引签名，arrays 只能使用字符串键进行索引：

interface $Zeros extends Type {
    type: Zeros<this['0']>;
}

以上不会触发无限递归错误。

使用 utility type apply时的错误

type apply<$T extends Type, Args> = ($T & Args)['type'];

type applyZeros = apply<$Zeros, [3]>;
//                ~~~~~~~~~~~~~~~~~~
// Type instantiation is excessively deep...

可以观察到正确的返回类型 ( [0, 0, 0] ) 是通过将鼠标悬停在 playground 中的applyZeros上推断出来的，因此触发错误的不是推理引擎。

罪魁祸首是类型检查器，因为它继续检查$T extends Type with $T = $Zeros 。

实际上，以下apply实现不会出现问题：

// no type constraint
type apply<$T, Args> = ($T & Args)['type' & keyof $T];

// shallow type constraint checking only the keys
type apply<$T extends (keyof $T extends keyof Type ? unknown : never), Args> =
    ($T & Args)['type' & keyof $T];

我的理解是类型约束$T extends { type: unknown }导致类型检查器将Zeros<this[0]>评估为Zeros<unknown> ，这导致无限递归。

我相信这个评估是没有必要的，因为T extends unknown总是正确的，因为可以跳过总是正确的检查。 我认为，与其评估类型，不如简单地检查密钥是否存在就足够了。

我提交了错误报告