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
I encountered a strange behavior of type inference about the generic arguments and intersection type. The error described below occurs only when the strictFunctionTypes option is enabled.
construn=<P1,P2>(makeProps1: (s: string)=>P1,makeProps2: ()=>P2,useBoth: (props: P1&P2)=>void)=>{};constfoo=(props: {n: number;b: boolean})=>{};// This works as expected.run(()=>({n: 1}),()=>({b: true}),foo);// But if the first argument function takes a parameter `s`, it results in a compile error.run(s=>({n: 1}),()=>({b: true}),foo);
Expected behavior:
The type of run is inferred correctly from run(s => ({ n: 1 }), () => ({ b: true }), foo) as below and the code compiles.
Here. Note that this problem occurs only when the strictFunctionTypes option is enabled.
Related Issues:
I could not find.
Other Investigation:
In the code below, the type inference works as expected:
construn2=<P1,P2>(makeProps1: (s: string)=>P1,makeProps2: ()=>P2,useProps1: (p: P1)=>void,useProps2: (p: P2)=>void)=>{};// The first argument function takes a parameter `s` but it does not change the type inference behavior.run2(s=>({n: 1}),()=>({b: true}),(p1: {n: number})=>{},(p2: {b: boolean})=>{});
So it seems that the error only occurs when the generic types (P1, P2) are used as intersection type.
The text was updated successfully, but these errors were encountered:
mmmm labeled it as a bug because I personally don't believe the strictFunctionTypes flag should affect inference results, for consistency. It might end up getting recategorized when we look at it in depth, but that's why I flagged it as "bug" initially.
No, because I think this inconsistent behavior should be reported as an issue even if this is not a bug.
But I didn't come up with your workaround. Thank you!
A small downside of the workaround is that the props of foo can contain any extra properties.
construn=<P1,P2,P3extendsP1&P2>(makeProps1: (s: string)=>P1,makeProps2: ()=>P2,useBoth: (props: P3)=>void)=>{};constfoo=(props: {n: number;b: boolean,s: string})=>{};// This compiles. But `s` in foo's props will be undefined in this case.run(()=>({n: 1}),()=>({b: true}),foo);
However it does not compile if the type inference works as expected.
construn=<P1,P2>(makeProps1: (s: string)=>P1,makeProps2: ()=>P2,useBoth: (props: P1&P2)=>void)=>{};constfoo=(props: {n: number;b: boolean,s: string})=>{};// Compile error as expected: `Types of parameters 'props' and 'props' are incompatible`run(()=>({n: 1}),()=>({b: true}),foo);
So it would be nice if this type inference works well with the strictFunctionTypes option.
Uh oh!
There was an error while loading. Please reload this page.
I encountered a strange behavior of type inference about the generic arguments and intersection type. The error described below occurs only when the
strictFunctionTypes
option is enabled.TypeScript Version:
Version 3.3.0-dev.20181221
Search Terms:
strictFunctionTypes
argument intersection type
generic argument
generic intersection type
Code
tsconfig.json:
source:
Expected behavior:
The type of
run
is inferred correctly fromrun(s => ({ n: 1 }), () => ({ b: true }), foo)
as below and the code compiles.This type is generated from
run(() => ({ n: 1 }), () => ({ b: true }), foo)
. I copied it from Playground's tooltip.Actual behavior:
It results in the compile error.
output of
npx tsc
:This is because the return type of
makeProps1
is inferred as{}
instead of{ n: number; }
.Playground Link:
Here. Note that this problem occurs only when the
strictFunctionTypes
option is enabled.Related Issues:
I could not find.
Other Investigation:
In the code below, the type inference works as expected:
So it seems that the error only occurs when the generic types (
P1
,P2
) are used as intersection type.The text was updated successfully, but these errors were encountered: