You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Checked type of conditional type isn't matched for constraint in true clause unless the type parameter is constrained #31700
changed the title [-]Type infer broken in 3.5[/-][+]Checked type of conditional type isn't matched for constraint in true clause unless the type parameter is constrained[/+]on May 31, 2019
Technically this is because we erase any in a substitution (or rather, we interpret it as unknown so as to not delete information). So a T extends any ? InstanceType<ReturnType<T>> : never is essentially InstanceType<ReturnType<T & unknown>> which is just InstanceType<ReturnType<T>> which is ofc an error. The others all formulate in the same way. Essentially, any as a conditional check does not disable type checking, like any as a constraint (accidentally!) does. #29571 would go a lot of the way to making the constraint cases behave like the conditionals (though it's still admittedly incomplete! it only replaces any at the top level of a constraint and not throughout the constraint type!)
So this is technically a regression, but it's an intended consequence of an intentional change, and what we have been looking at is making the constraint case behave in the same way, too (as why would a T extends any be any different than a T extends unknown???)
Ryan Cavanaugh (@RyanCavanaugh) if you want, we can discuss this, but after actually looking at it, everything seems in order except for our constraint behavior which we already acknowledge as wrong.
Activity
RyanCavanaugh commentedon May 31, 2019
Regressed between 3.3 and 3.4
[-]Type infer broken in 3.5[/-][+]Checked type of conditional type isn't matched for constraint in true clause unless the type parameter is constrained[/+]weswigham commentedon Jul 25, 2019
Technically this is because we erase
anyin a substitution (or rather, we interpret it asunknownso as to not delete information). So aT extends any ? InstanceType<ReturnType<T>> : neveris essentiallyInstanceType<ReturnType<T & unknown>>which is justInstanceType<ReturnType<T>>which is ofc an error. The others all formulate in the same way. Essentially,anyas a conditional check does not disable type checking, likeanyas a constraint (accidentally!) does. #29571 would go a lot of the way to making the constraint cases behave like the conditionals (though it's still admittedly incomplete! it only replacesanyat the top level of a constraint and not throughout the constraint type!)So this is technically a regression, but it's an intended consequence of an intentional change, and what we have been looking at is making the constraint case behave in the same way, too (as why would a
T extends anybe any different than aT extends unknown???)weswigham commentedon Jul 25, 2019
Ryan Cavanaugh (@RyanCavanaugh) if you want, we can discuss this, but after actually looking at it, everything seems in order except for our constraint behavior which we already acknowledge as wrong.
typescript-bot commentedon Jul 28, 2019
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.