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
Expected behavior:
the curried2 function should at least have the signature (x: number) => any, at best it would infer (x: number) => number
Actual behavior:
The args to the currried2 function are incorrect.
The reason why this is the case is confusing to me. Despite gFn being generic, and therefore harder for the compiler to understand what its ReturnType should be, the weird part is that this affects what fFn's argument type inference is. The type signature gFn should not affect how fFn is inferred.
Found another way to express safeCurry using a third generic type. This correctly discovers the argument type of curried2 now, but the return type is still not inferable. Also, the type T is only inferred to be {} and therefore typechecking safeCurry's parameters no longer works (shown in the curried3 function).
typeArgumentTypes<FextendsFunction>=Fextends(...args: infer A)=>any
? A
: neverconstsafeCurry=<T,Fextends(...args: any[])=>T,Gextends(fResult: T)=>any>(gFn: G,fFn: F)=>(...args: ArgumentTypes<F>): ReturnType<G>=>gFn(fFn(...args))// (x:number) => numberconstcurried=safeCurry((x: string)=>parseInt(x),(x: number)=>x.toString())// (x: number) => {}constcurried2=safeCurry(<T>(x: T)=>x,(x: number)=>x)// this should throw an error, though it does not// (x: number) => stringconstcurried3=safeCurry((x: string)=>x,(x: number)=>x)
TypeScript Version: 3.4.0-dev.20190213 (and 3.3.3)
Search Terms: generic function currying ArgumentTypes infer
Code
Expected behavior:
the
curried2
function should at least have the signature(x: number) => any
, at best it would infer(x: number) => number
Actual behavior:
The args to the
currried2
function are incorrect.The reason why this is the case is confusing to me. Despite
gFn
being generic, and therefore harder for the compiler to understand what itsReturnType
should be, the weird part is that this affects whatfFn
's argument type inference is. The type signaturegFn
should not affect howfFn
is inferred.Playground Link: playground link
Related Issues:
The text was updated successfully, but these errors were encountered: