Inconsistencies in assignability rules around top-level-like signatures
Opened this issue · 2 comments
🔎 Search Terms
assignability any never signature
🕗 Version & Regression Information
- This is the behavior in every version I tried
⏯ Playground Link
💻 Code
// source assignable to the target
const target1: (...args: any) => any = (...args: never) => 'foo'
// same source, but target now has *identical* return type as the source and all of a sudden it fails
const target2: (...args: any) => 'foo' = (...args: never) => 'foo'
// similar issue, target has the same return as in `target1` (any) but this time both source and target have **identical** extra leading parameter and it fails
const target3: (arg: unknown, ...args: any) => any = (arg: unknown, ...args: never) => 'foo'
// similar issue, target has the same return as in `target1` (any) but this time both source and target have **identical** `this` parameter and it fails
const target4: (this: unknown, ...args: any) => any = function (this: unknown, ...args: never) { return "foo"; };🙁 Actual behavior
Assignability rules behave weirdly/inconsistently in those simple examples
🙂 Expected behavior
I'd expect more consistent results
Additional information about the issue
relates to #55667 - the fact examples 2-4 error is the reason why that issue exists
🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.
Similar Issues
Here are the most similar issues I found
- (69%) microsoft/typescript#38284: Compatibility error when callback has void return type
- (67%) microsoft/typescript#36310: Strange behaviour with assignability and generics
- (67%) microsoft/typescript#43945: Assignable judging rules is not consistent between variable and function
- (67%) microsoft/typescript#55603: Covariance, contravariance and assignability
- (67%) microsoft/typescript#56379: Inconsistency when assigning a never type parameter to any[] type parameter
- (66%) microsoft/typescript#49262: (Almost) arbitrary functions are assignable to an assertion-function-typed variable
- (66%) microsoft/typescript#30098: Type compatibility works incorrectly with strictFunctionTypes flag and variables declared using typeof keyword
- (66%) microsoft/typescript#61676: A contextually-typed signature coming from correlated union can't be assigned back to source of its contextual type
- (66%) microsoft/typescript#35624: lookup type incorrectly becomes intersection type
- (66%) microsoft/typescript#48663: Union tuple type in rest argument can't accpect less argument.
- (66%) microsoft/typescript#21823: identical conditional types with a callable constituent not assignable to each other
- (66%) microsoft/typescript#32442: Functions with same intersection and conditional type in parameter list not assignable to each other
- (66%) microsoft/typescript#4661: assignment semantics for callable object types
- (65%) microsoft/typescript#27118: Assignability rule for conditional types needs to require check types and distributivity to be identical
- (65%) microsoft/typescript#42582: Type '(arg: number) => void' is not assignable to type '(arg: unknown) => void'.
If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.
We can look at what "fixing" this would do. It's probably best to approach this with both a theoretical (here's what the rules should be) and empirical approach (here's what DT and RWC turn up). I don't have high hopes on this, though - people often do need a "really, just any call signature, I do not care" type that isn't needlessly invariant.