Contextual inference of functions in tuple types failures
See original GitHub issueBug 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.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:10 (4 by maintainers)
Top Results From Across the Web
Use typed identity functions to guide type inference
But when you use tuples or string literal types, this will sometimes go wrong. This post explores using identity functions with carefully ...
Read more >Type inference and type annotations - Mypy documentation
Type inference is bidirectional and takes context into account. The value expression [1, 2] is type checked with the additional context that it...
Read more >Harmonizing Classes, Functions, Tuples, and Type ...
types. Surprisingly, we find variance for function types and tuple ... best-effort type inference algorithm4 for type arguments to both classes and methods....
Read more >Type Errors - Pyre
Invariance, combined with type inference, comes with a few gotchas. ... If strict mode is turned on, Pyre will error when a function...
Read more >Why is my generic function not monomorphized for a tuple?
You write "I know from context that E<T> instances will always be TisTupleVariant1 or TisTupleVariant1 ". But that is a fact that you...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
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 attest1
.