GeezerVison

Down to one failed testcase now.

All tests should be passing now. In terms of implementation details, I still need to figure out how to robustly:

• Retrieve the parameter symbol associated with a given argument in a CallExpression
• Obtain a workable signature from things like interface Foo { (bar: Bar): Baz } so I can retrieve the parameters associated with arguments

That aside, I think it would be good to start looking at examples of tricky cases where either the implementation or the proposed semantics blow up.

Herrington Darkholme (@HerringtonDarkholme) Thanks for the feedback! This is not intended to be a mergeable implementation of parameter inference; the goal is to demonstrate that it is possible to sensibly infer parameter types recursively without breaking everything in the compiler, and that it's possible to do so incrementally, reverting to noImplicitAny when a sensible inference cannot be made.

This is useful because when converting a new project to TypeScript, you often end up either disabling noImplicitAny and getting any everywhere, or manually propagating types up the call graph by adding parameter types to every function expression. Some kind of middle-ground would be useful, especially if this allows you to automatically generate explicit types for top-level APIs more accurately.

I covered only invocation expressions here because these seemed easiest to implement for a POC (and mirror the example from #15114), but the same concept extends to assignment from parameter, operator usage, etc.

I have recently worked on something similar to this in #14786. I started off with inferring from function body, but putting it to usage, changed my mind. most functions do not just use the parameter as is, they usually look at one ore more properties from it.. the result of the inference from the function body is always more of a constraint than a type really.. you end up with things like { kind: number } instead of Node, or { length: number } instead of Array which correct.. but not what a human would have thought about.. it gets complicated as the type gets more complex, and then you have these anonymous types that really mean nothing to the developer..

The other problem is this disables checking on the parameter all together. true that an implicit any inference does that as well, but at least you have a way to flag these as errors in --noImplicitAny.

I think the right place for this work is quick fix/ refactoring to help the user migrate to TS. The bar is low here for accuracy, since the user is doing an explicit action and will be reviewing the result anyways. Feel free to look at #14786, and contribute changes.

Mohamed Hegazy (@mhegazy) The overall goal of this and #17428 is to have the type <T extends { length }>(a: T) => T["length"] ascribed to a => a.length. This type means nothing to the developer when they really meant to talk about Array#length, but this is fine: the inferred type is sufficiently polymorphic that applying it to [1, 2, 3] will correctly produce number, and incorrectly applying it will produce an error.

Inferring things in this way ensures the function demands no more specificity in its parameters, and promises no less specificity in its return type, than what its implementation dictates.

It is true that inferring from the body will defer discovery of any type errors in the function implementation to the point where the function is invoked, but this is a worthwhile tradeoff for the significant decrease in verbosity and the increased ease of converting existing codebases to TypeScript.

As an example, if you do inference in this manner, it becomes more feasible for the typechecker to interact directly with plain JS modules that don't have any explicit typings.

#17428 is a breaking change.. a big one mind you. inferring constraints from the body of functions makes it less so, but still not completely. I would like to see a full proposal for this if you have one.

Mohamed Hegazy (@mhegazy) I'm going to be on vacation in a bit, and will spend some time to see if can come up with a proposal/reference implementation. That way you'll have a concrete list of thousands of broken testcases to point to when you reject the proposal 😉

That way you'll have a concrete list of thousands of broken testcases to point to when you reject the proposal

This is not the intention of my earlier comment.. I think if we are going to consider a major change, we should have the full picture, rather than having it spread on multiple smaller issues. In general this has a better chance of a positive outcome.

It is also important to acknowledge the proposal in #17428 is a breaking change, and a viable proposal needs to consider how it can be added/phased in with limited disruption to the system. Assuming we can make a fundamental change of behavior like this is with no mitigation is not realistic.. we have experience with similar changes with limiting any type evolution to under --noImplicitAny, and we have experimented with doing out-of-band inference in #14786. So having a proposal with this in mind would be very helpful.

Mohamed Hegazy (@mhegazy) I totally agree with you regarding the necessity of a proper proposal, my last comment was in jest. Exactly how much of a breaking change it would be, and whether it is possible to come up with a compromise that doesn't break 90% of existing TypeScript code is something I'm interested in myself.