You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expected tuple type as function return value is not infered from written code #53911
I have an issue when expecting a tuple as a function return value and trying to return a tuple without explicitly specifiying that it is a tuple.
TypeScript assumes that I am returning any Array, although the syntax of the code is that of a tuple.
I have the following function:
(value)=>[value.some((element)=>(element))]// NOK
The type of value is : (parameter) value: [boolean, boolean, boolean, boolean, boolean, boolean]
The expected return type is [boolean]
With the above function, I get the following type error from TypeScript:
I get the following error:
Argument of type '(value: [boolean, boolean, boolean, boolean, boolean, boolean]) => boolean[]' is not assignable to parameter of type '(value: [boolean, boolean, boolean, boolean, boolean, boolean]) => [boolean]'.
Type 'boolean[]' is not assignable to type '[boolean]'.
Target requires 1 element(s) but source may have fewer.
🙂 Expected behavior
I would expect to not get any error, since I used the "some" method that returns a boolean, and I put it in an array with [], which insures that I have one element. For me, the types seem coherent.
How could TypeScript handle this correctly ?
If there's no contextual type information available to indicate that the result should be a tuple TypeScript errs on the side of returning an array. This is by design.
Ok, but in this case the returned value can't be anything than a tuple with one element, e.g. [boolean], right ?
Couldn't TypeScript have a way of figuring it out ? What is the context for this design choice ?
In most cases the values are used as arrays, and inferring a tuple instead would be cumbersome (and it would have been a massive breaking changes, as tuples were added way after arrays).
If contextually it can be inferred that it's to be used as a tuple, it will be a tuple. Otherwise you can add a type annotation.
In general inferring the very-narrowest type for a function leads to suboptimal behavior in a lot of cases. Inference tries to pick the type that accurately reflects what's going on without being overspecific, but can't always know what you meant to do.
Ok, thanks for your responses.
Too bad for the tuple lovers out there, but I guess it makes sense that the tuple is the new kid on the block and still needs to prove his worth to be deemed inferable against the big array boss !
Maybe this "tuple auto inference" could be part of the ts configuration options ?
Have a nice day !
Jonathan Fady (@jonathanfady) You can write [..] as const to get TS to infer a tuple type in cases where it can’t do so automatically. This is safer than using an explicit type assertion like as [boolean].
Jonathan Fady (@jonathanfady) You can write [..] as const to get TS to infer a tuple type in cases where it can’t do so automatically. This is safer than using an explicit type assertion like as [boolean].
Bruce Pascoe (@fatcerberus) Not sure this works as you expected. If I use my previous example, I get the following error in the editor with as const :
(value) => [value.some((element) => (element))] as const
The type 'readonly [boolean]' is 'readonly' and cannot be assigned to the mutable type '[boolean]'.ts(4104)
Activity
MartinJohns commentedon Apr 19, 2023
If there's no contextual type information available to indicate that the result should be a tuple TypeScript errs on the side of returning an array. This is by design.
jonathanfady commentedon Apr 19, 2023
Ok, but in this case the returned value can't be anything than a tuple with one element, e.g.
[boolean], right ?Couldn't TypeScript have a way of figuring it out ? What is the context for this design choice ?
MartinJohns commentedon Apr 19, 2023
In most cases the values are used as arrays, and inferring a tuple instead would be cumbersome (and it would have been a massive breaking changes, as tuples were added way after arrays).
If contextually it can be inferred that it's to be used as a tuple, it will be a tuple. Otherwise you can add a type annotation.
RyanCavanaugh commentedon Apr 19, 2023
In general inferring the very-narrowest type for a function leads to suboptimal behavior in a lot of cases. Inference tries to pick the type that accurately reflects what's going on without being overspecific, but can't always know what you meant to do.
jonathanfady commentedon Apr 20, 2023
Ok, thanks for your responses.
Too bad for the tuple lovers out there, but I guess it makes sense that the tuple is the new kid on the block and still needs to prove his worth to be deemed inferable against the big array boss !
Maybe this "tuple auto inference" could be part of the ts configuration options ?
Have a nice day !
fatcerberus commentedon Apr 20, 2023
Jonathan Fady (@jonathanfady) You can write
[..] as constto get TS to infer a tuple type in cases where it can’t do so automatically. This is safer than using an explicit type assertion likeas [boolean].jonathanfady commentedon Apr 21, 2023
Bruce Pascoe (@fatcerberus) Not sure this works as you expected. If I use my previous example, I get the following error in the editor with
as const:Do you have any thoughts on this ?
typescript-bot commentedon Apr 23, 2023
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.