Description
🔎 Search Terms
overload, multiple call signature
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about overloads
⏯ Playground Link
💻 Code
interface Not{
(x:false):true // signature 1
(x:true):false // signature 2
(x:boolean):boolean // signature 3. Unclear whether this should be declared or not
}
declare var not:Not
const notAny = not(true as any) // true; but should be `boolean`
// ^?
type X = ReturnType<Not> // boolean; false if signature 3 is omitted
// ^?
const notBoolean = not(true as boolean) // boolean; error if signature 3 is omitted
// ^?🙁 Actual behavior
x types as true, the first signature of the overload.
🙂 Expected behavior
x should be boolean, the return type of signature 3.
Additional information about the issue
Note that #14107 would obviate the need for signature 3.
Originally discovered based on PR Feedback.
It is unclear to this author whether the implementation signature belongs in a pure declaration.
The FAQ indicates the implementation signature will typically not be externally visible:
When having at least one overload signature declaration, only the overloads are visible. The last signature declaration, also known as the implementation signature, does not contribute to the shape of your signature.
Previous discussion suggests the "catch-all" should actually be visible for consumers:
The intended thing for users to do is ... Have a "catch-all" overload, last, that represents the behavior of the function when overload resolution is ambiguous, whose return type should be the union of all other signatures' return types