Home > Software engineering >  Avoiding inferring generics from multiple arguments in Typescript?
Avoiding inferring generics from multiple arguments in Typescript?

Time:05-28

Consider this function:

function fn<T>(a: T, b: T[]): T {}

I'd like it to infer T from a, then check b against T. Instead, TS is inferring T from both a and b. E.g.:

fn(1, [1, 'str']);

This returns number | string. However, I want T to be inferred as number, so this would throw an error like "number | string isn't assignable to number". Is this possible?

CodePudding user response:

There is an alternative approach:


type Primitives =
    | string
    | number
    | bigint
    | boolean
    | symbol
    | null
    | undefined

type BackwardInference<T, P=Primitives> =
    P extends any ? T extends P ? P : never : never;

declare function fn<T>(a: T, b: BackwardInference<T>[]): T

fn(1, [45]) // ok

fn('str', ['hello']) // ok

fn(42, ['str']) // expected error

Playground

Because TS infers literal type if first argument is a primitive, we can loose inference strictness a bit. It means when first will be literal 42, second argument will be expected as number and not 42

CodePudding user response:

You could provide an explicit type:

declare function fnA<T>(a: T, b: (T extends T ? T : never)[]): T
fnA<number>(1, [2, 'str'])
// Type 'string' is not assignable to type 'number'.(2322)

Or do something like:

declare function fnB<T>(a: T, b: (T extends T ? T : never)[]): T
fnB(1, [1, 'str']);
// Type 'string' is not assignable to type '1'.(2322)

This forces the compiler to have to examine the type of a to figure out the type of b.

But this seems to infer a more specific type than number, so this doesn't work:

fnB(1, [1, 2]);
// Type '2' is not assignable to type '1'.(2322)

I think this breaks some heuristics Typescript about when a type automatically widens to number or string, and when it doesn't. And it is tricky for typescript to know just how tightly to constrain that type.

It will work fine if the first argument is a wider type like number, though:

const x: number = 1
fnB(x, [1, 2]); // fine

Or you could just, again, provide the type if you don't like how it got inferred:

fnB<number>(1, [1, 2]); // fine

Playground

CodePudding user response:

Though it's just an idea, you can maybe use HOF

declare const fn = <T,>(a: T) => (b:T): T
fn(1)([1,'str'])
// Argument of type '(string | number)[]' is not assignable to parameter of type 'number'.ts(2345)

But as @alex suggested, better to provide explicit type as long as you know it

CodePudding user response:

One option would be to make your function take two generic parameters while inferring both of them. This way you can easily codify the idea that the parameters are not codependent, but one depends on the other.

The main caveat is that to work with both literals and complex types, you will need to widen the literals which is verbose.

type WidenLiteral<T> =
    T extends string ? string :
    T extends number ? number :
    T extends bigint ? bigint :
    T extends boolean ? boolean :
    T extends symbol ? symbol :
    T;

function fn<T, U>(a: T, b: T extends U ? WidenLiteral<T>[] : never): T {
    return a;
}

fn(1, [2,3,4]); // Valid
fn('foo', ['bar']); // Valid
fn(true, [false, true]); // Valid
fn({ foo: 42 }, [{ foo: 1 }, { foo: 2 }]); // Valid

fn(1, ['foo']); // Invalid
fn(false, [0]); // Invalid
fn({ foo: 42 }, [{ foo: "1" }, { foo: 2 }]); // Invalid

Playground link.

  • Related