Repository navigation
Type parameter inference of function chained parameters and return values does not work. #38872
Description
I'm writing an API with life cycle methods that are called in a specific order. Each life cycle method can return a 'state' object that is passed to the next life cycle method. I would like the API to be strongly typed, and the type of the state parameters to be inferenced from the return type of the previous life cycle method.
TypeScript Version: 3.9.2, 4.0.0-dev.20200530
Search Terms:
chain inference inference parameter
Code
type Chain<R1, R2> = {
a(): R1,
b(a: R1): R2;
c(b: R2): void;
}
function test<R1, R2>(foo: Chain<R1, R2>) {
}
test({
a: () => 0,
b: (a) => 'a',
c: (b) => {
const x: string = b; // Type 'unknown' is not assignable to type 'string'.(2322)
}
});Expected behavior:
No error.
Actual behavior:
Error 2322 on const x: string = b
Removing the a parameter removes the error and works as expected, e.g.
// ...same as above...
test({
a: () => 0,
b: () => 'a',
c: (b) => {
const x: string = b; // no error
}
});Explicitly providing the parameter type also works, e.g.
// ...same as above...
test({
a: () => 0,
b: (a: number) => 'a',
c: (b) => {
const x: string = b; // no error
}
});Playground Link:
Activity
WearyMonkey commentedon Jun 1, 2020
Similar issue with a single function consuming its own return type:
https://www.typescriptlang.org/play?#code/C4TwDgpgBAyglgOwOYBsIB4BKAmAfFAXigG8AoKKAYwAoAjALihwEpGcBuUgX1NIDMArgkrA4AewRRgEAM7AseanzFjG8ZGgW5mJXj1LS51MhUqM6OgvhMUqEuVAAejBAIC2tCACdCUWp1soLwhgAS9JAAYAqB4uZk4gA
noc7c9 commentedon Jun 9, 2020
Facing the same issue.
I also found a possibly related issue: #38845
RyanCavanaugh commentedon Jun 15, 2020
Anders Hejlsberg (@ahejlsberg) design limitation or did I miss something?
ahejlsberg commentedon Jun 30, 2020
This is a design limitation. In the original example, the expressions provided for the
bandcmembers are context sensitive. We therefore perform a first phase of type inference where we use wildcard values for those members. In this first phase we successfully infernumberforR1, but we make no inferences forR2. We then use our inferences from the first phase to assign types to the contextually typed parameters, and since we have no inferences forR2, thebparameter is given typeunknown.In order to support this particular scenario we'd need additional inference phases, i.e. one per contextually sensitive property value, similar to what we do for multiple contextually sensitive parameters. Not clear that we want to venture there, and it would still be sensitive to the order in which object literal members are written. Ultimately there are limits to what we can do without full unification in type inference.