-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Wrong type inferred by returning a tuple #25516
Comments
It's not wrong, it's just less precise than it should be. I think this is fixable by improving the contextual type -> return type expression inference? |
Another example where a tuple inference would be desirable is in declare function f0<T extends any[]>(args: T): T;
declare function f1<T extends any[]>(...args: T): T;
f0(["a", 1]); // (string | number)[]
f1("a", 1); // [string, number] This is currently blocking a typesafe implementation of |
👍 Yes, the update to tuples to allow for |
This is not only related to functions. Variables are affected too: let test1: [number, string];
const a = [42, ''];
test1 = a; // error
|
@rrousselGit that is the intended behavior, because this code is legal: let test1: [number, string];
const a = [42, ''];
a[0] = "hello"; // Does not affect type system
test1 = a; // Unsound to allow |
This issue prevents normal creation of ES6 maps. This valid JS:
Doesn't compile due to But if you just cast it to the right type it works fine:
At least I think this is the same issue. Didn't want to make a duplicate issue. |
@rrousselGit By default, array literal declarations are given an array type, not a tuple type. There is a proposal to change this, and if you have a strong opinion to share I'd recommend chiming in because it is still in the feedback stage: #16896 |
+1 |
Randomly found this while looking through some other stuff - the OP has been fixed, at least as of TS 5.0. :) |
TypeScript Version: 3.0.0-dev.20180707
Code
Expected behavior:
Both expressions should be allowed
Actual behavior:
assignment for b works, assignment for a doesn't, as the compiler starts infering that the type for [item, !!item] is Array<string | boolean>.
The text was updated successfully, but these errors were encountered: