Optional Generic Type Inference

[kube]

#13487 added default generic types, but it's still not possible to infer a generic type:

type Return<T extends () => S, S = any> = S

Here S takes its default type any, but T could permit inference of a subset type of any for S:

const Hello = () => 'World'

type HelloReturn = Return<typeof Hello> // any

Here HelloReturn still has any type, and TypeScript could infer S as the literal type 'World', which is a subset of any.

Use Case

Here's an example of a fully declarative workaround for #6606, using generic type inference:

type Return<T extends () => S, S = any> = S

const Hello = () => 'World'

type HelloReturn = Return<typeof Hello> // 'World'

Default Type

If return of T is not a subset of S, it should throw an error:

type ReturnString<T extends () => S, S = string> = S

const Hello = () => 'World'
type HelloReturn = ReturnString<typeof Hello> // 'World'

const calculateMeaningOfLife = () => 42
type MeaningOfLife = ReturnString<typeof calculateMeaningOfLife> // ERROR: T should return a subset of String

Multiple Possible Type Inferences

The current implementation always returns the superset (which is just the default generic type), solving this issue would require to return the subset (the most precise type of all the inferred possibilities).

If a type has multiple possible type inferences, TypeScript should check that all these types are not disjoint, and that they all are subsets of the Default Generic Type.

The inferred type is the most precise subset.

[KiaraGrouwstra]

Thanks for creating this; I'll follow this thread as well.

A use-case I'm seeing here is clarifying types in function composition in the presence of generics on the first parameter-function -- that is, the one place that'd cause ambiguity to TS. (Related thread on this issue here.)

For example, for Ramda.js pipe<V0, T1, T2>(fn0: (x0: V0) => T1, fn1: (x: T1) => T2): (x0: V0) => T2;, there are three generics in total, but manually clarifying just the parameters of the entering function (in this case that's just V0) should suffice to hint TS as to what the types throughout the rest of the pipeline (here T1 as well as end return type T2) should be.

I'd see this proposal such as to enable that.
That said, I'd wonder if manually specifying = any should be required for this to work. (any seems like a default value so = any seems an oxymoron. Looks like this is discussed in #13609.)

[KiaraGrouwstra]

I just realized, might generics 'arities' not be used to disambiguate calls for functions with over-loaded type signatures? i.e. if foo has both <A>(): ... and <A, B>(): ..., if we wanted to invoke foo<myA>() so as to call the binary version, it might get misinterpreted as the unary version. I wonder how we could disambiguate that -- foo<myA, >?

[Dessix]

This would bring forward some nice possibilities in using inference to validate function parameters, and I'd very much like to see it happen 👍

[niieani]

Such a simple idea, but adds so much power to the language! Would love to see it happen!

Related:

• Allow skipping some generics when calling a function with multiple generics #10571
• Allow classes to be parametric in other parametric classes #1213

[EvanMachusak]

Yeah, yeah, but John, your language designers were so preoccupied with whether or not they could that they stopped to wonder whether or not they should.

Typescript is beginning to delve into the territory of too complicated. This is a hard shove off a cliff, in my opinion. Generic syntax is relatively well understood. Generic constraints are relatively well understood. Generic constraints in the form of a pair of lambda expressions would confuse almost everyone who's seen a generic in another language before.

[Dessix]

Evan Machusak (@EvanMachusak) Seeing the other languages in existence, is allowing inference of generics that complicated to the user in trade for the power it adds to the language?

P.S. Who's John?

[EvanMachusak]

Zoey (@Dessix) which other languages have generic inference patterns that resemble this proposal?

[niieani]

JavaScript's a dynamically typed language, and therefore it requires levels of expression in typing that statically typed languages don't. Nobody is forcing you to use these advanced ways of typing, better yet, you could even create a linter rule that forbids their usage.

On the other hand, this feature would enable proper and stricter typings for so many real-world use-cases that it would be very welcome, even if used only for typing external libraries DefinitelyTyped (@DefinitelyTyped). Moreover, I've mentioned two related, complex cases, in which this proposal trumps the necessity for additional complexity, i.e. it proposes to make the language simpler, rather than more complex.

[EvanMachusak]

Bazyli Brzóska (@niieani) Maybe I'm wrong here, but the appeal of TypeScript versus plain old JavaScript is that we can apply static language concepts and rules to a language (JavaScript) that lacks them. Our team became interested in it because it helped us discover bugs statically. I'm not following your argument that because JavaScript (not TypeScript) is dynamically (aka un-)typed, we must introduce exotic syntax to the language to serve use cases that I would argue are detracting from the purpose of TypeScript.

For example, there is a reason that anonymous types are typically only inferred at the scope level in most languages, and it's not just because of lazy compiler designers. #6606 is something that shouldn't be solved even if can be. If you need a reference to an anonymous type outside of a function scope, you should declare it as a type. It's extra effort to do so but making it too easy to produce and consume anonymous types means that a creative coder who happens to be intimately acquainted with this particular language power can easily get carried away and produce something utterly impossible to maintain, because trying to find the ultimate source of the type declaration you're working with several levels downstream requires that you scope into the function where the type was first created.

This leads me to your suggestion about linting. Yes, since I am speaking out against this proposal you can be sure I would look for a linter rule to prevent this from being used, but because it's a language feature, it's another syntax I have to learn and understand to be fluent in TypeScript which circles back to my original objection: that simply because we can doesn't mean we should. I love TypeScript's rapid evolution but we need to be careful to balance innovation and evolution with the needs of the ecosystem. Too much complexity, too much syntax can kill a language.

As for your final point that this would kill two birds with one stone: true, but only because you've created two monstrous birds in trying to do things that other languages disallow.

Compilers are smart. They're smarter than humans. That's why we need them.

But as we read code, we're compiling it in our heads. The complex use cases you're talking about solving require a level of type inference that while a compiler can do, a human being reading the code can't in most cases. You may be overestimating the average intelligence (or, as we get older, the average amount of caring) we will apply to a problem when reading code. In my view, this syntax proposal requires more horsepower than its added value merits, and that's why I think while it's a cool idea, it's just too much.

[KiaraGrouwstra]

Does this really add learning curve if it just mirrors param defaults in the expression language?
In function composition I'm not sure there's really a nicer way to clarify types.