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
declarefunctiongetMaybeNumber(): any;// declare function getMaybeNumber(): number | undefined;functioncheckNum(num?: number){if(!num){num=getMaybeNumber()||42;// if (!num) num = 42}if(num<50){thrownewError()};}
π Actual behavior
'num' is possibly 'undefined'.
π Expected behavior
type of num narrowed to number or widened to any
More information
The narrowing work correctly if the return type is not any.
The narrowing also works if using an if statement instead of a conditional expressions. Likely related to the design limitation that was mentioned in #50739. However given that type narrowing works if the return type is not any there is obviously some type inference possible in conditional expressions.
The text was updated successfully, but these errors were encountered:
The current behavior is the most-conservative since there's really no telling what is happening on that line of code, while still not completely wrecking type safety on num throughout the body of the function. I don't think a change in either direction as proposed is a net improvement.
Bug Report
π Search Terms
type inference any conditional expression
π Version & Regression Information
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
'num' is possibly 'undefined'.
π Expected behavior
type of
num
narrowed tonumber
or widened toany
More information
The narrowing work correctly if the return type is not
any
.The narrowing also works if using an
if
statement instead of a conditional expressions. Likely related to the design limitation that was mentioned in #50739. However given that type narrowing works if the return type is notany
there is obviously some type inference possible in conditional expressions.The text was updated successfully, but these errors were encountered: