-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad type inference under --strictFunctionTypes
#19576
Comments
I think this is an intended behavior. I would suggest annotate |
That does feel like |
I think the main problem is that an unresolved contextually typed literal takes precedence. The array is not a variable reference, it's a literal. What surfaces is the presumably evolving implicit |
One option here is to make no inferences form a fresh array literal. the parallel in an object literal case here would be: declare function mkList<T>(items: { 0?: T }, comparator: Comparator<T>): LinkedList<T>;
mkList({}, compareNumbers); // `number`, since no inferences are made from `{}` |
Yes, I think that would be the best approach, but only if the array is empty. |
Example of breaking soundness with an aliased type Comparator<T> = (x: T, y: T) => number;
declare const compareStrings: Comparator<string>;
declare const compareNumber: Comparator<number>;
function makeArray<T1, T2>(arr1: T1[], arr2: T2[], c1: Comparator<T1>, c2: Comparator<T2>) {
return {
arr1,
arr2
}
}
const arr: never[] = [];
const res = makeArray(arr, arr, compareStrings, compareNumber);
res.arr1.push("");
res.arr2.push(10); |
TypeScript Version: 2.7.0-dev.20171029
Code
Actual behavior:
The implicit evolving
never[]
type of the array literal is taking precedence, leading to unexpected results.The text was updated successfully, but these errors were encountered: