Repository navigation
Narrowing by checking for existence of key leads to never. #38608
Description
TypeScript Version: 3.9.2
Search Terms:
instanceof narrow derived
Code
class CustomError extends Error { extra: string = 'hello' }
const error: Error = new CustomError()
if ('extra' in error) {
// code path reached at runtime
error // type: never
} else {
// code path not reached at runtime
error // type: Error
}Expected behavior:
error inside the if block is still of type Error
Actual behavior:
error inside the if block is of type never
Related Issues:
None that seemed to match.
Activity
MicahZoltu commentedon May 16, 2020
It would be super cool if the type inside the
ifstatement wereError & { extra: unknown }, but I know TS doesn't currently narrow objects like this which I have accepted, so I would be fine with justErroras the type inside the if block.jcalz commentedon May 16, 2020
Duplicate of #21732? Or related anyway
MicahZoltu commentedon May 16, 2020
#21732 would be very cool to have and resolving that may (as a side effect) resolve this (depending how it is implemented), but I don't think this is a duplicate of that or needs to block on that necessarily.
Fix microsoft#38608
jack-williams commentedon May 19, 2020
This looks to be similar to #21517. There was some discussion here.
It's not quite clear what the behaviour should be for the singleton case. For a union I think it is clear you want to narrow down to
never, but for declared singletons there is some ambiguity. Then there is the case where you start with a singleton, narrow to a union, then back to a singleton from the union.A proposed fix is to not apply
innarrowing to singleton declared types. That is,innarrowing gets applied when either the type is a union, or the type is not the declared type (because of narrowing).RyanCavanaugh commentedon Jun 8, 2020
Anders Hejlsberg (@ahejlsberg) thoughts on desired behavior?
[-]Narrowing with instanceof by checking for existence of key leads to never.[/-][+]Narrowing by checking for existence of key leads to never.[/+]MicahZoltu commentedon Jun 9, 2020
Further simplified repro case:
The issue here is that just because
applehas a keyadoesn't mean it is no longer of type{}.ahejlsberg commentedon Jun 28, 2020
Ryan Cavanaugh (@RyanCavanaugh) I think our current behavior is quite odd. There's some good discussion in #21732, and I like Joe Calzaretta (@jcalz)'s suggestion of extending the current behavior to intersect with
Record<K, unknown>when the current behavior would otherwise have producednever. There are no doubt some details to work out to get that in place without breaking changes, but I think it makes sense to do so.Fix #38608 (#38610)