Rest parameters when overloading with optional

When overloading functions I sometimes use the following pattern:

export function foo(a: string): void;
export function foo(b: number): void;
export function foo(a: string, b: number): void;
export function foo(...args: [string] | [number] | [string, number]): void {
	/* ... */
}

This makes it easy to determine which of the prototypes is used, e.g. if args.length === 2 then args is known to be [string, number]. With more complex types (consider if instead of string and number you have two interfaces) this can simplify a great deal.

However, I cannot get this working when using optional parameters:

export function foo(a?: string): void;
//              ~~~ error TS2394: This overload signature is not compatible with its implementation signature.
export function foo(...args: [] | [string]): void {
	return;
}

I know I can simply add another overload without the optional parameter but the combinations would quickly become unmanageable.

export function foo(): void;
export function foo(a: string): void;
export function foo(...args: [] | [string]): void {
	return;
}

A more concrete example of this would be:

interface Foo {
  /* ... */
}

interface Bar {
  /* ... */
}

interface Baz {
  /* ... */
}

function awesomeFunction(foo?: Foo, bar?: Bar): void;
function awesomeFunction(baz: Baz, foo?: Foo, bar?: Bar): void;
function awesomeFunction(...args:
  | [Foo | undefined, Bar | undefined]
  | [Baz, Foo | undefined, Bar | undefined]
): void {
  /* ... */
}

Since I know that if args[0] is a Baz I would know the rest of the elements in args as well. It does however not work as seen above with the foo function.

Typing out all the permutations would become a lot of variants and typing out each parameter as arg1?: Foo | Baz, arg2: Foo | Bar, arg3: Bar means I have to typecheck for impossible variants.

Is there a way to work around this issue?

There's essentially a direct equivalence between function parameter lists and tuple types. In particular, optional function parameters like in (x?: string) => void correspond to optional tuple elements like [string?] (or, when you use tuple element labels, [x?: string]).

That means you could write your overload implementations like this:

function foo(a?: string): void;
function foo(...args: [string?]): void {
}

function awesomeFunction(foo?: Foo, bar?: Bar): void;
function awesomeFunction(baz: Baz, foo?: Foo, bar?: Bar): void;
function awesomeFunction(...args: [Foo?, Bar?] | [Baz, Foo?, Bar?]): void {
}

Indeed if the return types are identical for all the call signatures, you don't even need overloads:

function bar(...args: [a?: string]): void { }
// bar(a?: string | undefined): void

and a function accepting a union of rest tuples looks like an overloaded function when you call it:

function awesomeFunction(...args:
  [foo?: Foo, bar?: Bar] | [baz: Baz, foo?: Foo, bar?: Bar]
): void { }
// 1/2 awesomeFunction(foo?: Foo | undefined, bar?: Bar | undefined): void
// 2/2 awesomeFunction(baz: Baz, foo?: Foo | undefined, bar?: Bar | undefined): void

And while there are arguably a relationship between [string?] and [string] | [], there's probably no point in trying to force the compiler to see it when optional tuple elements are available.

Playground link to code