proper overloading for arrow functions

[DetachHead]

Suggestion

🔍 Search Terms

arrow function overload

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

it seems that the syntax for overloading arrow functions are more like a side effect of existing functionality (function interfaces/intersections), rather than an intentional language feature. as a result, it doesn't really work properly in most cases - see #33482

it would be nice if there was actual syntax for arrow function overloading like there is for normal functions

📃 Motivating Example

const foo: {
    (value: number): number
    (value: string): string
} = (value) => value

this is the most basic example of an overload i can think of, yet it doesn't work:

Type '(value: string | number) => string | number' is not assignable to type '{ (value: number): number; (value: string): string; }'.
  Type 'string | number' is not assignable to type 'number'.
    Type 'string' is not assignable to type 'number'.(2322)

as mentioned on #33482 (comment), function interfaces have a much broader purpose than overloads, meaning it has to protect against a potentially incorrect assignment in other scenarios. but here, that's obviously not what we want

perhaps a function overload type that looks something like:

const foo: overload {
    (value: number): number
    (value: string): string
} = (value) => value

💻 Use Cases

makes it easier to avoid using old function syntax

[RyanCavanaugh]

This immediately runs into difficulty because how do you check the body?

• Checking each overload independently is combinatorially explosive
• "Combining" the return types in this case immediately produces never and the function can't legally return

[DetachHead]

how do overloads work on normal functions? can it just do it the same way?

[nmain]

In the normal function case, there's a separate implementation signature which is not exposed to callers, and is allowed to be very weakly typed.

[fatcerberus]

That's true @nmain, but the compiler does still check if the overloads are compatible with the implementation signature. If I read it right, the suggestion is, there would be dedicated syntax for an overload type like in the example given:

const foo: overload {
    (value: number): number
    (value: string): string
} = someFunction;

then the compiler could just use the overload compatibility check in lieu of an assignability check.

[DetachHead]

an idea i came up with to solve the issue without adding any additional syntax is to improve the logic used to infer the type of the implementation when its types are omitted.

for example:

const foo: {
    (value: number): number
    (value: string): string
} = (value) => value

currently the value is inferred as (value: string | number) => string | number which is wrong. it should be instead inferred as <T extends string | number>(value: T) => T. that way you would get no errors on assignment, and you wouldn't have to do any casting in the impl

obviously this could get messy with some more complicated overloads though:

const foo: {
    (value: number, value2: string): number
    (value: string): string
} = (value1, value2) => value

in this case perhaps there could be a built in Overload interface to simplify the inferred type of the impl:

interface Overload<Parameters extends unknown[], Return> {
    parameters: Parameters
    return: Return
}

then the impl can be inferred as something like

<O extends Overload<[number, string], number> | Overload<[string], string>>(
    ...args: O['parameters']
) => O['return']

(though while playing around with this approach i ran into other issues such as #48345 and #46076)

[icywolfy]

@fatcerberus
Could the overload mechanism be similar to how function works?

@RyanCavanaugh Would this syntax have any glaring issues?

function foo(value: number): number;
function foo(value: string): string;
function foo(value: string|number): number|string { return value }

// idea
const foo2: (value: number) => number;
const foo2: (value: string) => string;
const foo2: (value: string|number): number|string = (value: string | number): number|string => value

[erquhart]

Probably the biggest issue is that re-declaring constants isn't valid js. The example provided in the OP is viable, though.

[icywolfy]

Probably the biggest issue is that re-declaring constants isn't valid js. The example provided in the OP is viable, though.

@erquhart The existing function overload syntax in TypeScript declares functions without a body, which isn't valid syntax either. Invalid JS syntax is not a limitation.

[DetachHead]

imo the example in the OP is better because you don't have to duplicate the function name nor do you have to add types to the implementation signature

[erquhart]

Yeah, fair - I was more thinking of js support for declaring functions that have already been declared, and doing so with constants feels a bridge further. But yeah, not materially different since neither is really valid, agreed. Your syntax is honestly preferable if using const this way isn't an issue.