Fix #38608

[Jack Williams (jack-williams)]

Fixes#38608

Narrowing an object to never using in when the value was not declared as a union seems like undesirable behaviour.

[Jack Williams (jack-williams)]

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this

[TypeScript Bot (typescript-bot)]

Heya Jack Williams (@jack-williams), I've started to run the extended test suite on this PR at 2609521. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Jack Williams (@jack-williams), I've started to run the parallelized community code test suite on this PR at 2609521. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[Jack Williams (jack-williams)]

Baseline changes:

VSCode fails on:

functionimproveError(err: Error): Error{if('errno'inerr&&err['errno']==='ENOENT'&&'path'inerr&&typeoferr['path']==='string'){returnnewError(nls.localize('ext.term.app.not.found',"can't find terminal application '{0}'",err['path']));}returnerr;}

Previously err would narrow to never and stuff just 'worked'. Now err stays as Error and we cannot index using 'errno'. Proposed fix:

functionimproveError(err: Error&{errno?: unknown,path?: unknown}): Error{// ....

Other diff looks unrelated.

[Wesley Wigham (weswigham)]

Rather than the declared type, shouldn't this just be looking at the input type? If we look at the declared type, it precludes things like

declarevarx: unknown;if(isAOrB(x)){if("aProp"inx){x;// A}elseif("bProp"inx){x;// B}elseif("cProp"inx){x;// never}}

since I'm pretty sure we just merged a fix to a lot of cases like that.

[Jack Williams (jack-williams)]

The fix that just went in was for discriminant property narrowing, which solved examples that are similar to yours, but it's a disjoint code path. Changing declaredType to type would revert to the original behaviour, but also have the correct behaviour here.

I've made a slight modification that narrows singletons if the current type is not the same as the declared type. This is abit of a hack, but in general working out the intent does not seem easy.

I added some discussion to the linked issue. The best thing might be to make no change at all.

[Nathan Shively-Sanders (sandersn)]

Wesley Wigham (@weswigham) what do you think? should we take this or not?

[Wesley Wigham (weswigham)]

Sure, this looks like both a pretty small change, and a pretty agreeable one now.

[Jack Williams (jack-williams)]

I'm happy to refresh this - just wondering whether to look into Anders' suggestion here? Maybe merge this and review that option later?

[Wesley Wigham (weswigham)]

🤷 I don't think we'll take this for the 4.1 RC this week, so there a few weeks you could experiment during until we're ready to start merging things for 4.2.

[Nathan Shively-Sanders (sandersn)]

Master is open for 4.2 PRs now.

[Wesley Wigham (weswigham)]

so Jack Williams (@jack-williams) you feel strongly one way or another with this now?

[Jack Williams (jack-williams)]

Wesley Wigham (@weswigham) I merged master on this and opened another PR that tried the & Record<..> approach. Are the bot user tests down, or did my change wreck everything? Other PR is here #41478.

Perf looked ok - some changes in the binder but I think they are unrelated.
EDIT: User test baselines seem ok with & Record<..> (haven't inspected them too much)

My preference for in narrowing would be to use & Record<..> - I think it is more useful whilst this is really a patch.

There are some subtleties which arise because in narrowing is always done using the current type, rather than with the declared type like discriminants.

As it is now, the following behave the same (with and without my changes):

typeAOrB={aProp: number}|{bProp: number};declarefunctionisAOrB(x: unknown): x is AOrB;declarevarx: unknown;declarevary: AOrB;if(isAOrB(x)){if("aProp"inx){x.aProp;}elseif("bProp"inx){x.bProp;}elseif("cProp"inx){const_never: never=x;}}if("aProp"iny){y.aProp;}elseif("bProp"iny){y.bProp;}elseif("cProp"iny){const_never: never=y;}

But it is not the case that similar discrimant code behaves the same:

typeA={kind: 'a'}typeB={kind: 'b'}typeAorB=A|B;declareconstx: unknown;declareconsty: AorB;declarefunctionisAorB(x: any): x is AorB;if(isAorB(x)){if(x.kind==="a"){}elseif(x.kind==="b"){x;}else{x// B;}}if(y.kind==="a"){}elseif(y.kind==="b"){}else{y;// never;}

When you consider having in use & Record you get different behavior when ordering clauses:

declareconstw: AOrB;if("aProp"inw){w// A}elseif("bProp"inw){w// B}// w is never from hereelseif("cProp"inw){w}else{w}

but check cProp earlier and:

declareconstw: AOrB;if("aProp"inw){w// A}elseif("cProp"inw){w// w is { bProp: number } & Record<"cProp", unknown>}elseif("bProp"inw){w// B}else{w// never}

• We could make the order not matter by narrowing from the declared type (for unions), but that might be a subtle breaking change for in.
• We could say the order does matter and just deal with the odd cases with the recommendation to check non-mentioned properties first.
• We could never narrow to never, but this would remove exhaustiveness checking for in, which I think could be quite a break?

I think the second option is reasonable but I haven't been able to check user tests yet.

[Wesley Wigham (weswigham)]

Narrowing for in is a little... Ideals-based? anyway, so I think whichever pattern matches more real world intent with usage like this is probably better. How we I can't say I've seen many in checks in the real world to build up an intuition of what one might "expect" these checks to imply, so I'm not sure I can be a great judge of which is better. Hm.

[Jack Williams (jack-williams)]

Would this be a way forward?

The current PR is ready and the other PR (#41478) is nearly ready but needs some tests, to scan through the user tests, and to write up a description of the implemented behavior. I can do that work this week. At that point, it probably comes down to a discussion within the team to see if they want to consider moving forward with #41478, otherwise this can be merged.

Merging this would not preclude #41478 at a later date, I think. In most cases this PR just changes some never's into original types, and #41478 would extend those types with intersections for new properties.

[Nathan Shively-Sanders (sandersn)]

I agree, let's merge this one now. I'll add #41478 to the design meeting agenda.