Repository navigation
Type Narrowing for discriminated unions not narrow enough #12955
Description
Activity
Your last example works because the object literal is contextually typed by the parameter type. But in the first
const kdeclaration there is nothing to indicate that you wantkindto have a literal type so it is widened tonumber. It works when you have a type annotation because you're then contextually typed, just like the function call.Narrowing further based on some use in another (perhaps remote) part of your program would be a non-local effect that has the potential to be very confusing (as in, why did my type all of a sudden switch to a literal type?). I don't think that is desirable.
Anders Hejlsberg (@ahejlsberg) Thanks for the response. I understand that feedback and pretty much assumed that was precisely what was happening. It seems possible to try narrowing the type being inferred to see if any narrower type satisfies the constraints of the program. I don't see how that would be "bad" behavior as if the type-checker ever manages to become fully satisfied I would see that as a win?
Specifically in the cases where there exist valid types in scope ( literals in this case ) that are narrower than the inferred type, it seems prudent to try them. Many javascript libraries would construct these literals and then use them later in the way I have shown in this example.
- locked and limited conversation to collaborators
on Jun 19, 2018
TypeScript Version: 2.2.0-dev.20161215
Code
Expected behavior:
Would expect it to try narrowing the type to a literal from the enumeration if the general enum doesn't satisfy other type expectations.
Actual behavior:
When defined as a literal function argument, typescript further narrows the type, otherwise it does not? This seems perhaps non-awesome or at least the compiler maybe ought to try further narrowing as a constraint to see if it type-checks the entirety of the program?