Meta-issue: Use Full Unification for Generic Inference?

[RyanCavanaugh]

Search Terms

unification generic inference

Suggestion

Today, TypeScript cannot retain or synthesize free type parameters during generic inference. This means code like this doesn't typecheck, when it should:

function identity<T>(arg: T) { return arg; }
function memoize<F extends (...args: unknown[]) => unknown>(fn: F): F { return fn; }
// memid: unknown => unknown
// desired: memid<T>(T) => T
const memid = memoize(identity);

Use Cases

Many functional programming patterns would greatly benefit from this.

The purpose of this issue is to gather use cases and examine the cost/benefit of using a different inference algorithm.

Examples

Haven't extensively researched these to validate that they require unification, but it's a start:

#9366
#3423
#25092
#26951 (design meeting notes with good examples)
#25826
#10247

[essenmitsosse]

Wouldn't that be a solution:

function identity<T>(arg: T) { return arg; }
function memoize<F extends <G>(...args: G[]) => G,G>(fn: F): F { return fn; }

// memid<T>(T) => T
const memid = memoize(identity);

Which wouldn't work with non generic functions, but this could be fixed like that:

function memoize<F extends ( <G>(...args: G[]) => G ) | ( (...args: G[]) => G ),G>(fn: F): F { return fn; }

// memid<T>(T) => T
const memid1 = memoize(identity);

function stupid(arg: string) { return arg; }
// memid (string) => string
const memid2 = memoize(stupid);

It's definitely not pretty, but it seems to do the job.

[RyanCavanaugh]

Correct. memoize is possible to write a workaround for, but in more complex cases it isn't possible to fix in user code.

[dragomirtitian]

@essenmitsosse

This approach would work only for really simple cases. If for example there is any constraint on the type parameter of identity we will get an error, and there really is no way to forward the generic type constraint. Also if the number of type parameters is variable we again have an issue, but this could be solved with a number of overloads.

@RyanCavanaugh
Not sure if this is in scope here, but I have seen people often struggle with generic react components and HOCs. There really is no good way to write a HOC that forwards generic type parameters, maintains generic type constraints and removes some keys from props. Not sure if this will ever be possible but one can dream :). A simple example of what I am talking about:

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>

function HOC<P extends { hocProp: string }>(component: (p: P) => void): (p: Omit<P, 'hocProp'>) => void  {
  return null!;
}

// Works great for regulart components
// const Component: (props: { prop: string }) => void
const Component = HOC(function (props: {  prop: string, hocProp: string}) {});

// Curenly an error, ideally we could write HOC to get 
// const GenericComponent: <T extends number | string>(p: {  prop: T }) => void
const GenericComponent = HOC(function <T extends number | string>(p: {  prop: T, hocProp: string}) {

})

[yortus]

@RyanCavanaugh is #29791 another example of something that could be addressed by this? You mention the absence full unification in your comment there.

[airlaser]

I'm currently running into this issue, or at least what I think is this issue. I have a class that extends an interface that uses generics. I have to explicitly type the parameters on methods in my class even though the type is already explicitly stated on the interface. If I don't, it complains that I didn't type it and calls it an any. If I type it incorrectly, it tells me the type is wrong, so clearly it knows what type it's supposed to be.

An example:

interface FolderInterface<FolderInfo> {
      getFolderName: (folder: FolderInfo) => Promise<string>;
}

class FolderImplementation implements FolderInterface<WindowsFolder> {
    getFolderName = async (folder: WindowsFolder) => apiCallForFolderName(folder);
}

In FolderImplementation if I don't explicitly type folder it complains that Parameter 'folder' implicitly has an 'any' type. If I purposefully type it incorrectly (for example, as string) it complains that Type '(folder: string) => Promise<string>' is not assignable to type '(folder: WindowsFolder) => Promise<string>'.

Would this be fixed by this? It would be a lot less verbose if I didn't have to re-explicitly-type everything.