Let TypeScript determine the appropriate generic type automatically

Question

Let TypeScript determine the appropriate generic type automatically

Below is a simplified code snippet that encounters an issue inferring Set<number> for the inner property:

function test<S>(state: S, fn: (value: { outer: Set<S> }) => void) {}
function numberFn(value: { outer: Set<{ inner: Set<number> }> }) {}
test({ inner: new Set() }, numberFn)
//     ^____
// Type 'Set<unknown>' is not assignable to type 'Set<number>'.
//   Type 'unknown' is not assignable to type 'number'.ts(2322)

In my actual code, I have numerous calls like test with various types for the generic parameter of Set, and currently these types are not exported. Explicitly typing them would be troublesome, so I was hoping TypeScript could automatically infer them, but unfortunately, I have not been able to achieve that.

To gain a better understanding and attempt to solve the issue, I conducted some tests:

function test1<T>(input: { arr: T[] }, value: { val: T }) {}
test1({ arr: [] }, { val: 5 })
// function test1<number>(input: {
//   arr: number[];
// }, value: {
//   val: number;
// }): void

The above test worked successfully. However, the following test did not yield the desired result:

function test2<T>(input: { arr: Array<T> }, value: { val: T }) {}
test2({ arr: new Array() }, { val: 5 })
// function test2<any>(input: {
//   arr: any[];
// }, value: {
//   val: any;
// }): void

This discrepancy may be due to special handling of [] in comparison to generic types in general. Interestingly, when attempting the same scenario using Set instead of Array with reversed argument order, the correct type inference was achieved:

function test3<T>(value: { val: T }, input: { arr: Set<T> }) {}
test3({ val: 5 }, { arr: new Set() })
// function test3<number>(value: {
//   val: number;
// }, input: {
//   arr: Set<number>;
// }): void

To work around this issue, explicit type inference can be performed in TypeScript, although it may become convoluted, as shown below:

function test<S>(state: S, fn: (value: { outer: Set<S> }) => void) {}
function numberFn(value: { outer: Set<{ inner: Set<number> }> }) {}
test(
  { inner: new Set() } as Parameters<typeof numberFn>[0] extends { outer: Set<infer S> } ? S : never,
  numberFn,
)

Is there a way to rewrite the code so that TypeScript can correctly infer the type for state, similar to what occurs in test3?

typescript

Answer 1

Answer №1

Typically, TypeScript struggles to deduce both generic type arguments and contextual types simultaneously. When you invoke the test() function, the type argument for S should be inferred from numberFn, implying that the argument {inner: new Set()} needs to match against {inner: Set<number>}. Consequently, new Set() should be interpreted within the context of Set<number>, leading the constructor's type argument to be inferred as number. Unfortunately, the inference algorithm doesn't follow this sequence correctly. At some point, it gives up on contextual typing for state, causing the inference of the Set constructor's type argument to fail and default to unknown. Since Set<unknown> is not compatible with Set<number>, errors occur.

function test<S>(state: S, fn: (value: { outer: Set<S> }) => void) { return state; }      

function numberFn(value: { outer: Set<{ inner: Set<number> }> }) { }

test({ inner: new Set() }, numberFn) // error
//     ~~~~~
// 'Set<unknown>' is not assignable to 'Set<number>'

This issue of conflicting generic and contextual inference represents a broader limitation of TypeScript. The main open problem related to this can be found in microsoft/TypeScript#47599. While progress has been made in addressing this, such as seen in microsoft/TypeScript#48538, there will always be scenarios that aren't fully supported.

The simplest solution is to adapt and use Set<any> instead of Set<unknown>, since any is more flexible than unknown. Note that I altered test() to return

state</code, demonstrating that <code>S

is still inferred as {inner: Set<number>}, resulting in the returned value being of type Set<number> (not Set<any>):

const inner = test({ inner: new Set<any>() }, numberFn).inner; // okay
//    ^? const inner: Set<number>;

If precise inference is a top priority, one approach to gain the necessary control is breaking down test() using currying:

function curryTest<S>(fn: (value: { outer: Set<S> }) => void) {
    return (state: S) => {
        return state;
    }
}

In this modified version, curryTest() only takes fn, inferring

S</code. It returns another function that solely accepts <code>state

, firmly establishing S. There are no simultaneous inferences happening here:

const inner2 = curryTest(numberFn)({ inner: new Set() }).inner; // okay
//    ^? const inner2: Set<number>;

A similar outcome might be achievable in an un-curried function by reordering arguments, as certain parts of the inference process operate sequentially through the argument list. If not, this alternative remains viable.

Link to interactive code

Answer 2

Typically, TypeScript struggles to deduce both generic type arguments and contextual types simultaneously. When you invoke the test() function, the type argument for S should be inferred from numberFn, implying that the argument {inner: new Set()} needs to match against {inner: Set<number>}. Consequently, new Set() should be interpreted within the context of Set<number>, leading the constructor's type argument to be inferred as number. Unfortunately, the inference algorithm doesn't follow this sequence correctly. At some point, it gives up on contextual typing for state, causing the inference of the Set constructor's type argument to fail and default to unknown. Since Set<unknown> is not compatible with Set<number>, errors occur.

function test<S>(state: S, fn: (value: { outer: Set<S> }) => void) { return state; }      

function numberFn(value: { outer: Set<{ inner: Set<number> }> }) { }

test({ inner: new Set() }, numberFn) // error
//     ~~~~~
// 'Set<unknown>' is not assignable to 'Set<number>'

This issue of conflicting generic and contextual inference represents a broader limitation of TypeScript. The main open problem related to this can be found in microsoft/TypeScript#47599. While progress has been made in addressing this, such as seen in microsoft/TypeScript#48538, there will always be scenarios that aren't fully supported.

The simplest solution is to adapt and use Set<any> instead of Set<unknown>, since any is more flexible than unknown. Note that I altered test() to return

state</code, demonstrating that <code>S

is still inferred as {inner: Set<number>}, resulting in the returned value being of type Set<number> (not Set<any>):

const inner = test({ inner: new Set<any>() }, numberFn).inner; // okay
//    ^? const inner: Set<number>;

If precise inference is a top priority, one approach to gain the necessary control is breaking down test() using currying:

function curryTest<S>(fn: (value: { outer: Set<S> }) => void) {
    return (state: S) => {
        return state;
    }
}

In this modified version, curryTest() only takes fn, inferring

S</code. It returns another function that solely accepts <code>state

, firmly establishing S. There are no simultaneous inferences happening here:

const inner2 = curryTest(numberFn)({ inner: new Set() }).inner; // okay
//    ^? const inner2: Set<number>;

A similar outcome might be achievable in an un-curried function by reordering arguments, as certain parts of the inference process operate sequentially through the argument list. If not, this alternative remains viable.

Link to interactive code

Let TypeScript determine the appropriate generic type automatically

Answer №1

Similar questions

What are the drawbacks of removing comments from polyfills.ts in Angular CLI when using Internet Explorer?

Retrieve information using Angular's EventEmitter

Steps for exporting various elements from a .vue file

Add fresh data key and corresponding value into an array containing multiple objects

Proceed to the subsequent 'then' statement promptly

What is the best way to pass a URL as a prop in Next.js without encountering the issue of it being undefined

What can cause a problem with the reduce function that populates an empty object with keys in TypeScript?

Struggling to compile TypeScript code

Trouble Loading TypeScript Class in Cast Situation

Issue with comparing strings in Typescript

Tips for linking a composite element while utilizing React's forward ref (attribute is not present on forwardRefExoticComponent)

Guide to leveraging tanstack table v8 for sorting data within a specific date range

Troubleshooting a Pulumi script in Azure using Typescript and encountering difficulties with function writing

A guide on obtaining the date format according to locale using Intl.DateTimeFormat within JavaScript

The concept of an undefined object without a question mark is frowned upon

The JSON property is showing as undefined despite the fact that the variable holding the data is filled with a JSON object

Transforming a TypeScript enum into an array of objects

The Angular Material DatePicker fails to update in accordance with the Moment locale settings

What is the best way to display toastr messages in an Angular application?

Utilize the class or interface method's data type