请在 /**/
处完成请求并选择 orange
的选项。
今天,我们展示
(property) orange: unknown
[
{
"name": "orange",
"kindModifiers": "",
"kind": "property",
"displayParts": [
{
"text": "(",
"kind": "punctuation"
},
{
"text": "property",
"kind": "text"
},
{
"text": ")",
"kind": "punctuation"
},
{
"text": " ",
"kind": "space"
},
{
"text": "orange",
"kind": "propertyName"
},
{
"text": ":",
"kind": "punctuation"
},
{
"text": " ",
"kind": "space"
},
{
"text": "unknown",
"kind": "keyword"
}
],
"documentation": [],
"tags": []
}
]
这与我们如何决定显示属性有关 - 我们只需请求 p
缩小到的类型,而不是单个属性的类型。这实际上是另一个更奇怪的区别的一部分,缩小属性并不也会缩小包含值的类型。
最近有一些关于我们是否可以这样做的讨论;然而,我在这里有些怀疑。除了这一点之外,向用户展示他们实际使用的类型会很好。
这可能会有点昂贵;但总体而言,缩小应该会变得更便宜。从理论上讲, #51525 可以避免很多工作,并使这里的开销非常低。
3条答案
按热度按时间vaj7vani1#
我原本的理解是,在一般情况下,缩小基于属性的类型保护器的对象过于复杂/昂贵/通过创建笨重的交集来使事情变得复杂,这就是为什么我们有区分联合的原因。还有一个问题是如何处理应用于
a.b.c.d
的类型保护器-缩小是否会递归传播,因为这感觉起来可能会很快变得复杂。a2mppw5e2#
这是可以解决这个问题的方法,但我并不是说我们应该提出一个新的通用缩小方案。我只是建议对于像计算显示
completionEntryDetails
这样的事物,我们应该获得该符号的缩小类型。但是,对于包含对象快速信息不同步这样的事物来说,这可能已经很奇怪了。
pbpqsu0x3#
我有一个更简单的情况,也会出现这种情况:
https://www.typescriptlang.org/play?noUnusedLocals=true&noUnusedParameters=true&checkJs=true&allowJs=true&module=1&emitDeclarationOnly=true&stripInternal=true&ts=5.1.6#code/MYewdgzgLgBCBGArAXDA3gBwE4gwflWiwEswBzGAHxgFcwATAUwDNTH6YBfGAXnW4CGEGALABPANwAoKaEggANowB0CkGQAUCRMuy4AlNID0RmGfMXzAPTwzizGFqS6cGfeilm5ERSrWbtFwNpMxNLcLMbKU4pIA