Contextual inference of functions in tuple types failures

[david-shortman]

Bug Report

🔎 Search Terms

contextual inference
tuple inference

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about contextual inference

⏯ Playground Link

Playground link with relevant code

💻 Code

class State<T> {
  // Returns a function that takes t, applies it to all provided fns,
  // and pushes the results through the projector
  public getProjectionFactory<R extends readonly unknown[], P>(
    ...args: [
      ...fns: { [i in keyof R]: (t: T) => R[i] },
      projector: (...a: R) => P
    ]
  ): (t: T) => P {
    // ignoring implementation...
    return undefined as any;
  }
}

type Foo = { foo: number };
const aFooState = new State<Foo>();

const testOne = aFooState.getProjectionFactory(
  ({ foo }) =>  foo,
  () => 2,
  // 👇 incorrectly inferred to be [unknown, number]
  (...args) => ({ result: args })
);

// 🚫 failureOne is [unknown, number] instead of expected [number, number]
const { result: failureOne } = testOne({ foo: 3 });

// 👇 incorrectly infers fns to be ((t: Foo) => unknown)[]
const testTwo = aFooState.getProjectionFactory(
  () => 1,
  () => 2,
  <A extends readonly unknown[]>(...args: A) => ({ result: args })
);

// 🚫 failureTwo is unknown[] instead of expected [number, number]
const { result: resultTwo } = testTwo({ foo: 3 });

🙁 Actual behavior

The projector and fns in the tuple type examples are incorrectly inferred.

🙂 Expected behavior

projector should be inferred as (...args: [number, number]) => { result: [number, number] } in the first test example.

fns should be inferred as [(t: Foo) => number, (t: Foo) => number] in the second test example.

[RyanCavanaugh]

This looks like a consequence of not having unification; see #30134. In the other examples, there is a candidate for Results (or equivalent) being provided through a contextual type, but this isn't present at test1.

[david-shortman]

This looks like a consequence of not having unification; see #30134. In the other examples, there is a candidate for Results (or equivalent) being provided through a contextual type, but this isn't present at test1.

I'm confused why there isn't a candidate for Results present in test1. If I provide an anonymous function without typed parameters for the projector, then the argument for that method is contextually inferred (i.e., Results was inferred from the fns arguments):

const test4 = projectResults(getCounter, n => ({ values: [n] as const }));
const test4Result: { values: readonly [number] } = test4(state); // ✅ values is inferred correctly

playground

Why does providing an anonymous function behave differently than providing a defined generic function?

[david-shortman]

An interesting twist!

Using the helper type NoInfer, I can show that Results can being correctly inferred. The contextual typing for the return value of the projector function only fails when providing a generically typed anonymous function vs a untyped anonymous function:

type State = { counter: number };

const state = { counter: 1 };

const getCounter = (s: State) => s.counter;

// Uses conditional type to delay inference, per https://dev.to/davidshortman/weird-ts-types-using-contextual-typing-and-deferred-inference-to-plan-an-alien-conquest-bm8
type NoInfer<T> = T extends infer U ? U : never;

/**
 * Projects the results of the `fns` using the `projector`
 */
declare function projectResults<S, Results extends unknown[], Projection>
  (...args: [...fns: Array<(s: S) => unknown>, projector: unknown] & [...fns: { [i in keyof Results]: (s: S) => Results[i] }, projector: (...args: NoInfer<Results>) => Projection])
  : { results: Results, projector: (s: S) => Projection };

// Provide an anonymous function with generic argument
const test1 = projectResults(getCounter, <A extends readonly unknown[]>(...args: A) => ({ values: args }));
// 👆 contextual inference fails for the return value of the projector, as seen by the inferred function signature:
// function projectResults<State, [number], { values: readonly unknown[]; }>(...args: [...fns: ((s: State) => unknown)[], projector: unknown] & [(s: State) => number, (args_0: number) => { values: readonly unknown[]; }])
const test1Results: [number] = test1.results; // ✅ okay
const test1ProjectedValues: readonly [number] = test1.projector(state).values; // ⚠️ Type 'readonly unknown[]' is not assignable to type 'readonly [number]'

// Provide an untyped anonymous function
const test2 = projectResults(getCounter, (...args) => ({ values: args })); // args is contextually inferred to be Results
// 👆 contextual inference works for the return value of the projector per the inferred function signature:
// function projectResults<State, [number], { values: [number]; }>(...args: [...fns: ((s: State) => unknown)[], projector: unknown] & [(s: State) => number, (args_0: number) => { values: [number]; }])
const test2Results: [number] = test2.results; // ✅ okay
const test2ProjectedValues: readonly [number] = test2.projector(state).values; // ✅ okay

playground

[david-shortman]

The wild thing is that, for the failing test case, the inferred type for the argument list of the projector is correct!

function projectResults<State, [number], { values: readonly unknown[]; }>
  (...args:
    [...fns: ((s: State) => unknown)[], projector: unknown] &
    //                     👇args are correctly inferred!        👇 but the values, which should be the same as the args, are unknown[] instead!
    [(s: State) => number, (args_0: number) => { values: readonly unknown[]; }])

[david-shortman]

I've updated the title and issue description to match my updated findings.

[RyanCavanaugh]

Repros this complex rarely result in actionable defects; this isn't something we'd be able to look at.

[david-shortman]

@RyanCavanaugh I have simplified the reproduction to the two following failures (playground):

class State<T> {
  // Returns a function that takes t, applies it to all provided fns,
  // and pushes the results through the projector
  public getProjectionFactory<R extends readonly unknown[], P>(
    ...args: [
      ...fns: { [i in keyof R]: (t: T) => R[i] },
      projector: (...a: R) => P
    ]
  ): (t: T) => P {
    // ignoring implementation...
    return undefined as any;
  }
}

type Foo = { foo: number };
const aFooState = new State<Foo>();

const testOne = aFooState.getProjectionFactory(
  ({ foo }) =>  foo,
  () => 2,
  // 👇 incorrectly inferred to be [unknown, number]
  (...args) => ({ result: args })
);

// 🚫 failureOne is [unknown, number] instead of expected [number, number]
const { result: failureOne } = testOne({ foo: 3 });

// 👇 incorrectly infers fns to be ((t: Foo) => unknown)[]
const testTwo = aFooState.getProjectionFactory(
  () => 1,
  () => 2,
  <A extends readonly unknown[]>(...args: A) => ({ result: args })
);

// 🚫 failureTwo is unknown[] instead of expected [number, number]
const { result: resultTwo } = testTwo({ foo: 3 });

[RyanCavanaugh]

Reduced a bit further and tried alternate definitions. It seems like the return type computation is not being sufficiently deferred; the usual tricks here don't work.

// Attempted definition
declare function project1<R extends readonly unknown[]>(
  ...args: [
    ...fns: { [i in keyof R]: (t: string) => R[i] },
    projector: (...a: R) => unknown
  ]
): void;

// Desired behavior in OK case:
project1(
  () => 0,
  () => "",
  (...args) => {
    // args: [number, string]
  }
)

// Fails with context-sensitive argument
project1(
  () => 0,
  () => "",
  n => n.substring(0), // <- n: string (correct)
  (...args) => {
    // args: [number, string, unknown]
    // but should be
    // args: [number, string, string]
  }
)

// Having *all* context-sensitive arguments: implicit any
project1(
  // s: implicit any
  s => s.length,
  (...args) => {

  });

// Alternate definition; same behavior
type ReturnsOf<T extends readonly unknown[]> = { [K in keyof T]: T[K] extends (...args: any[]) => infer R ? R : never; };
declare function project2<R extends readonly ((n: string) => unknown)[]>(
  ...args: [
    ...fns: R,
    projector: (...a: ReturnsOf<R>) => unknown
  ]
): void;

// Alternate definition yields s: implicit any in all cases
declare function project3<R extends readonly ((n: string) => unknown)[]>(
  ...args: [
    ...fns: R & (readonly ((s: string) => unknown)[]),
    projector: (...a: ReturnsOf<R>) => unknown
  ]
): void;

// Projector-first definition without using tuple spread is OK
declare function project4<R extends readonly ((n: string) => unknown)[]>(
  projector: (...a: R) => unknown,
  ...fns: R
  
): void;
project4(
  (...args) => {

  },
  s => s.length,
 );

[david-shortman]

I'd be willing to help dive into this issue, but I'm not familiar with the codebase, and I don't know much about how the parser or compiler operates. Are there any docs to help onboard people to contribute to development?

[RyanCavanaugh]

@david-shortman CONTRIBUTING.md has links to what we have, but this is probably a 9.5 out of 10 difficulty bug if it's even possible to fix at all

[Andarist]

I might be wrong but this one feels related to #53018 . I'll have to recheck if my WIP fix for that issue makes any difference here.

[david-shortman]

Looks like one of the failing cases in the original issue is now passing as of v5.1.6 in the playground (and does not work in 5.0.4 and earlier)

// ✅ correctly infers fns to be [args_0: (t: Foo) => number, args_1: (t: Foo) => number]
const testTwo = aFooState.getProjectionFactory(
  () => 1,
  () => 2,
  <A extends readonly unknown[]>(...args: A) => ({ result: args })
);

// ✅ success is expected [number, number]
const { result: success } = testTwo({ foo: 3 });

I'm interested whether #54029 impacts the remaining failing case.

[Andarist]

The fix for the above can be found here so it was likely fixed by #53036