Skip to content
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

Closed
wants to merge 9 commits into from

Conversation

sandersn
Copy link
Member

Fixes #3667. Fixes #1373. This code is based on a previous approach at #6118 and still needs some cleanup.

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.
@sandersn
Copy link
Member Author

sandersn commented Aug 30, 2016

@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.

@appsforartists
Copy link

@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 noImplicitAny. That way, there's no backwards compat problem (because noImplicitAny means any code that could be contextually typed going forward would be explicitly typed now). Moreover, if you end up with weirdness (like typeof item === Item instead of Subitem), you can fix it with explicit typing.

@sandersn
Copy link
Member Author

sandersn commented Oct 4, 2017

@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 --noImplicitAny. So the feature might not prevent that many real bugs.

@appsforartists
Copy link

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. 😃

@typescript-bot
Copy link
Collaborator

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.

@lsagetlethias
Copy link

Is there another PR incoming for this?
Most of the issues about this I've seen are closed.

Also I've found nothing neither on the Roadmap or StackOverflow.
Is there any weirdly way to achieve the "basic"

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 ?

@jakebailey jakebailey deleted the contextually-type-inherited-properties-WIP branch November 7, 2022 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants