-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type predicate doesn't narrow down function overload (but assertion works) #58660
Comments
I don't see what this has to do with overloads, per se... you could remove those call signatures and the problem persists. Looks like #46266 (comment) alludes to this... type predicates don't seem to work to discriminate destructured discriminated unions. Not sure if there's another issue open for it somewhere. |
hey @jcalz! you're correct, I just assumed that maybe there's some special logic that's used for choosing the overload. What I find surprising is that type assertion works. Would it be possible to replicate this behavior for type predicates? |
Overloads only matter for the caller. The type checker doesn't care about any overloads when checking the function body (which is why you need a separate implementation signature); what narrowing you do see here, with the assertion function, is just normal discriminated union narrowing. If you were to declare the implementation as, e.g. Anyway, it's likely just a bug that the assertion works but the type predicate doesn't. |
Please provide a minimal repro; this doesn't sound based on the description like it needs 70 lines to demonstrate |
Why can't I deduce the type of data?? |
Please help to see why the type of data cannot be inferred, |
Function overloads don't have any effects on narrowing. For this case you'd have to write something like function typeFun(...args: [TestType.A, TypeAData] | [TestType.B, TypeBData]): void {
const [type, data] = args;
switch (type) {
case TestType.A:
typeAFun(data); // Why can't I deduce the type of data??
break;
case TestType.B:
typeBFun(data as TypeBData);
break;
default:
}
} |
This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
π Search Terms
type predicate, function overload, discriminating unions
π Version & Regression Information
β― Playground Link
https://www.typescriptlang.org/play/?ts=5.4.5#code/C4TwDgpgBAgg+gFSgXigAxgEgN4GdgBOAlgHYDmAvmgNwBQokUAQoiukzvseVXfeNHgkA9iTgAbIsAgEAhuLYByGAGUAIoroNoLEWMnS5C1IqbrNtWgGNR+KNoAKBCABMiV2dKGiJUmfLYACgA3eQAuKFkSEABKCNCFIlxYOD1fQwDkAD4oBIA6fFkCYFwAdSkAC0DlRRi6GxI7R2c3D2ldHwN-YygQ8MjouNyApOZUzr8jFBz8wuKyyuqYWr4AMwBXEitgIlEoVZJm13dPCG99Sfk+8Qio2PiR5PP07qhsKGdgdYISYfEC4BFErlYBVGoxChrTbbXa-WS4XAyYAASVwzy6Rmut0GtwRSOSCSgo3RlwU2FoUCJq16AEIjq1TjBrjEYm8KZT7BUCMIAO5QEgQPkAUQI3IIgQARAA5YTASJQLikMg0iV1dkUWga6y2OX0k5eIIJbH3P5Ep6sbJ-AFAhagpYrbWNXUCJzHNoQJiG-p3IaE0YsJCW2aA+YgsFMB20DZbHZ7A5691Mo0DE1+81Id6fb6-YM2sP2upa6MwvbwxHFVFJ704yJ4+am4mscmUojUwJ0l0tfVnZms5sc0HcvkC4Wi4Ti6Wy+WK8gqtWUjVF6GxuF1lG4JhYlNDMv4hvJANslttjuQV0M9q9o8Drm8-mCqAisWSmVy2QKwhKud0BeayzFlcoCsZxGXHTdZAieAEAAGigMAAAYIhIdYAFsACMZCGZD0JkKNl1hICQK8MDAjQiIA1ghCIhnMgsNQjCCDwmMCOAiBQIITc8i4gBtWQAHkOMo+CAF0Il4yDECEpD6JkYSoAAHygbiyLGGC4MQj9uDIOSoDonCCDZdlW0CBNGUCfiOJZftKQaXBhHECA8nEYQyECABZTwKgKABHYpAgQlkfygDVj0CeNOzdMyLKYKz2Rs2x7Mc5zXI80EfL8gL52Cyx2V3Cs0XMgSYqC2zEqclz3M89LgH8+DApyyksx+KB4LoJdmL2VjTgAJhgEiIJSNIMXkKT+Rkgg9IYpiS1+LrpF6kiVI6C4MnEUaaMm3CAJYoiIAWjjAi4vJeKKoTRKUgaSVW0bsIYuTFOU8jxhW7p1s-cgdM2gzySM1YTIii8zmel5MWi2KOSAhKHPKlKqtwXyasyoKQqpMLDgB7sru6QrLJiazIcaMrksqtL4Yyuqsq1XK10rYHhvEHHivZUroeJ1KvLJxGKb4dkmt+VrNSAA
π» Code
π Actual behavior
After the type predicate, the second parameter isn't narrowed down to number, hence the error:
After the assertion, the code works as expected.
π Expected behavior
Type predicate to do the same narrowing as type assertion.
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered: