Prevent substitution types from leaking out of non-deferred conditionals#54894
Prevent substitution types from leaking out of non-deferred conditionals#54894Andarist wants to merge 2 commits intomicrosoft:mainfrom
Conversation
typescript-bot
added
the
For Uncommitted Bug
Andarist
changed the title
Andarist
changed the title
typescript-bot
added
For Backlog Bug
weswigham
left a comment
weswigham
left a comment
There was a problem hiding this comment.
This doesn't quite feel like the right fix - I'm actually OK with substitution types exiting conditional boundaries, it's useful in many ways - in fact, it's sometimes the only way chained conditionals like SplitString<Cast<T, string>> typecheck. Naturally, using the intersection means these cases will still work... but the ux when you see these "narrowed" types will get a bit (ok, a lot) worse.
Honestly, a much better fix is noting that in getPropertyTypeForIndexType we use isTypeAssignableToKind to make these errors, which is... not great (any type-kind based analysis is suspect, given how generics work). But so long as we are, updating isTypeAssignableToKind to intersect substitutions is probably ok.
| } | ||
| if (result.flags & TypeFlags.Substitution) { | ||
| const substitution = result as SubstitutionType; | ||
| result = getIntersectionType([substitution.baseType, substitution.constraint]); |
There was a problem hiding this comment.
Use getSubstitutionIntersection, if this sticks around.
|
superseded by #57113 |
3 participants
fixes #54886