Bug Report
🔎 Search Terms
partial application generic bind return type
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about bind, generics, partial application
⏯ Playground Link
Playground link with relevant code
💻 Code
functiona<TextendsArray<any>>(anArray: T): T{returnanArray;}letb=a.bind(undefined,[1]);// b has type () => any[]letc=()=>a([1]);// c has type () => number[]// Further simplifiedfunctionidentity<Type>(arg: Type): Type{returnarg;}letd=identity.bind(undefined,"test");// d has type () => unknownlete=()=>identity("test");// e has type () => string🙁 Actual behavior
The types of b and c are different, and the types of d and e are different.
🙂 Expected behavior
I'd expect them to both have the same type (b that of c, () => number[]), d that of e () => string), as the expressions are doing the same thing (arrow function vs bind for partial application of a function).
This limitation is noted in a comment to the "Strict bind, call, and apply methods on functions" PR, but I couldn't find an actual issue referencing this behaviour.
That comment is also mentioned as a known limitation in a similar issue which was closed in #28920, but unfortunately that pr only fixes the issue when binding only this, and not other parameters.
Bug Report
🔎 Search Terms
partial application generic bind return type
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
The types of b and c are different, and the types of d and e are different.
🙂 Expected behavior
I'd expect them to both have the same type (b that of c,
() => number[]), d that of e() => string), as the expressions are doing the same thing (arrow function vs bind for partial application of a function).This limitation is noted in a comment to the "Strict bind, call, and apply methods on functions" PR, but I couldn't find an actual issue referencing this behaviour.
That comment is also mentioned as a known limitation in a similar issue which was closed in #28920, but unfortunately that pr only fixes the issue when binding only this, and not other parameters.