Wrong type inferred by returning a tuple
See original GitHub issueTypeScript Version: 3.0.0-dev.20180707
Code
const a: Array<[string, boolean]> = ["foo", "baz"].map(item => [item, !!item]);
const b: Array<[string, boolean]> = ["foo", "baz"].map(item => { const value: [string, boolean] = [item, !!item]; return value;} );
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>.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:10
- Comments:8 (2 by maintainers)
Top Results From Across the Web
Typescript inferring Tuple as Array Incorrectly - Stack Overflow
1 Answer 1 · use a const assertion · give test an explicit tuple type.
Read more >Tuples - Visual Basic | Microsoft Learn
Starting with Visual Basic 15.3, Visual Basic can infer the names of tuple elements; you do not have to assign them explicitly. Inferred...
Read more >typing — Support for type hints — Python 3.11.1 documentation
In the function greeting , the argument name is expected to be of type str and the return type str . Subtypes are...
Read more >Wrong type in error message note when return type is tuple
When the tuples are of different lengths, the error message will use the types of the elements from the expected type in its...
Read more >Type Errors - Pyre
Updating the return annotation, or the value returned from the function will resolve this error. 8: Incompatible Attribute Type. Pyre will error if...
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 FreeTop 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
Top GitHub Comments
Another example where a tuple inference would be desirable is in
f0
below:This is currently blocking a typesafe implementation of
Promise.all
without overloads.+1 for different return types for different promises in promise.all