-
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
Contextually type inherited properties (WIP) #10610
Conversation
Doesn't work yet. Stopping to revert this: any in contextual signatures which breaks a lot of code that isn't this: annotated.
The new baselines expose a problem: contextually typing a method with an default parameter now ignores the type of the default parameter's initialiser. For example, ```ts interface I { m(): void; } class C implements I { m(a = 0, b?) { } } ``` gives both `a` and `b` the type `any`, even though `a` could have the type `number` inferred from its initialiser.
@DanielRosenwasser here is the WIP version of inherited typing. It still has some contextual typing machinery in there that I will see if I can remove, but it's already ready for more extensive real-world testing. |
it now uses intersections, which is much cleaner to write
@sandersn Looks like this hasn't been touched in over a year. What's the status here? @DanielRosenwasser, @alexeagle , and I were talking the other day about #6118, and wondering if a path forward would be to only enable it with |
@appsforartists: Briefly, irreconcilable problems with every approach we've tried. However, we haven't given up hope that some solution exists; we just haven't tried for 6 months or so. @DanielRosenwasser, if you want to resurrect this maybe we can talk about it in person to understand whether hiding it behind a flag would work. On a pessimistic note, I re-read my notes on this PR that I made on #6118, and I noticed that the one bug it finds is also found by |
From my POV, it's less about finding bugs and more about making code easier to maintain. Mix-ins, for instance, are a pain currently in TypeScript because you have to maintain each one's signature in two places (once in an interface and again in the implementation). Then again, you clearly see value in solving this, so I don't need to sell you on it. 😃 |
Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it. |
Is there another PR incoming for this? Also I've found nothing neither on the Roadmap or StackOverflow. interface I {
f(n: number): string;
p: string;
}
class C implements I {
f = n => n.toString(); // n is correctly typed as `number`
p = undefined; // correctly retains type `string`
} from #6118 ? |
Fixes #3667. Fixes #1373. This code is based on a previous approach at #6118 and still needs some cleanup.