GeezerVison

This is such an important missing feature in TS, I really hope this gets picked up.

Nathan Shively-Sanders (@sandersn) Anders Hejlsberg (@ahejlsberg) Can you take a look?

best addition since conditional types! Ramda badly needs this. /cc Ika (@ikatyang)

Any updates from the TS team? TypeScript needs this feature.

Kevin Donnelly (@kpdonn) Thanks for taking time to experiment with this. It definitely would be nice to be able to infer free type variables--but it is quite complicated to do right, as I'm sure you've discovered. Your particular approach works for some scenarios, but there are several common ones that really only can be solved using a unification algorithm. For example:

declare function compose<A, B, C>(f: (x: A) => B, g: (y: B) => C): (x: A) => C;
declare function arrayToList<T>(x: Array<T>): List<T>;
declare function box<U>(x: U): { value: U };

const f = compose(arrayToList, box);  // Should infer <T>(x: Array<T>) => { value: List<T> }

Ideally this would infer type <T>(x: Array<T>) => { value: List<T> } for f, but it requires a more capable unification algorithm to do so, along the lines of what Marin Marinov (@gcnew) prototyped. A number of the challenges are outlined in #15016 (comment)). It would definitely be complex to integrate unification in a non-breaking manner.

But I totally understand the value of the feature and it is certainly something I continue to think about.

I'd like to add that your typical FP library is not the only place where the lack of this feature is making things hard. Writing react components with generics, even though it's supported, is pretty much impossible because of this (as soon as you drop your component into a typical HOC, you'll get {} everywhere).

For React, we've moved away from using HOCs and moved to using render props instead since it plays a lot better with TypeScript at the moment.

Is this patch dead? Perhaps TS could create some tests they want to see pass, and we can either get the job done or bounty it off?

I realize the degree of complexity involved here, but is there any way we could get an update from a TS core gatekeeper?

Despite the (already considerably high) level of sophistication & expressiveness of the type system, it is still effectively impossible to do real, type-safe FP beyond naïve function composition. A proper implementation of this feature would be a massive step forward.

If we could at least know what the goalposts are for getting this accepted, I'm sure more than a few of us (myself included) would be happy to step up and help, but it's hard to want to put up the effort when it feels like you might just as likely be shouting into the void, so to speak.

Anyway, I appreciate that this is a large open source project with many competing priorities, I appreciate the efforts made on it, and your time and attention. Thanks.

Nate Abele (@nateabele)

If we could at least know what the goalposts are for getting this accepted, I'm sure more than a few of us (myself included) would be happy to step up and help, but it's hard to want to put up the effort when it feels like you might just as likely be shouting into the void, so to speak.

Three things here.

First, we do have far too many open PRs at the moment, and we have "dropped the ball" on following up on community members. I apologize for that, and we're taking steps to address this: all open PRs have been assigned to a core team member for investigation and follow-up. For transparency, this backlog started building while I was on paternity leave coinciding with two engineers taking other opportunities, and we haven't backfilled those positions yet, so we're quite short-staffed -- but we need to reprioritize things here to keep things moving. My goal here is that we don't any actionable community PRs sitting open for more than a few days.

Second, a key aspect of this is "actionable" - we're basically staffed at a level where we can readily accept PRs for bugs and features which are already "approved", meaning that we understand the impact on the language and are comfortable accepting a correct PR implementing that change. We're also barely staffed to work through the current backlog of 1,200 open "Suggestions" before the heat death of the universe. A PR for a language feature with no approved issue tracking it is just not something we're equipped for in terms of process: The design needs to be hammered out and approved before the PR can be looked at, otherwise there are just too many free variables in play. Again for transparency, while there's substantial overlap between design and implementation on the team, in general there are different people and processes addressing design issues vs implementation issues.

This is basically to say that this PR is "outside our process", hence the "Experiment" tag and subsequent lack of responses. Without an issue describing the design being implemented, the only thing we (as code reviewers) can comment on is whether the code is facially correct (not useful), not whether or not we cant merge it. IOW, we (as designers) can't take PRs to the design process because it's not useful to just put the code up on screen and reverse engineer what's happening. A useful next step to make this more actionable would be a fresh issue outlining what proposal is being implemented and how.

Third, the comments above from Anders Hejlsberg (@ahejlsberg) are effectively blocking to the design being implemented. Speaking with him offline, we're in agreement that only a full (or "nearly full") unification algorithm will produce correct inferences in all the cases of interest here. Going back to an issue outlining the proposed design would be a clearer venue for going over various examples and how a potential unification algorithm would handle them.

Kevin Donnelly (@kpdonn), thanks for this prototype. I'm cleaning up our PRs and since the original bug was closed with #30215, I'm going to close this.

We continue to think about how to make inference better, so we would appreciate any more discussion on the topic. Prototypes are good too!