Repository navigation
Display narrowed type of properties in completionEntryDetails #51526
Description
interface Palette {
red?: Color;
green?: Color;
blue?: Color;
}
type Color = string | [number, number, number];
function checkOrange(p: Palette) {
if (typeof p === "object" && "orange" in p && typeof p.orange === "number") {
p./**/
}
}Request completions at /**/ and select the option for orange.
Today, we show
(property) orange: unknown
(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": []
}
]This has to do with how we decide to display properties - we simply request the type of what p is narrowed to, not the type of individual properties. This is actually part of another weirder distinction, where narrowing a property doesn't also narrow the containing value's type.
Recently there's been some discussion around whether we could do that; however, I am a bit skeptical here. Short of that, it would be nice to show users the actual type they're using.
This could get a little bit expensive; but narrowing in general should get cheaper. In theory, #51525 could avoid much of the work, and make the overhead here very low.
Activity
[-]Display narrowed type of property in `completionEntryDetails`[/-][+]Display narrowed type of properties in `completionEntryDetails`[/+]fatcerberus commentedon Nov 14, 2022
I was under the understanding that, in the general case, narrowing the parent object of a property-based type guard was too complex/expensive/complicates things by creating unwieldy intersections, and that’s why we have discriminated unions. There’s also the issue of what to do with a type guard applied to
a.b.c.d- does the narrowing propagate recursively, because that feels like it could quickly get out of hand in terms of complexity.DanielRosenwasser commentedon Nov 15, 2022
Right - that's a thing that would fix this, but I'm specifically not saying we should come up with a new general narrowing scheme. I'm only suggesting that for things like calculating display for
completionEntryDetails, we should get the narrowed type of that symbol.But maybe that's already weird for things like quick info on the containing object being out of sync.
JulioC commentedon Sep 28, 2023
I have a simpler case where this also happens:
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