Repository: TypeScript
Issue: Dependent arguments assignability to overloaded functions
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms

overloads, dependent, tuple signatures

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

It would be like if dependent parameters (declared using tuple types) could satisfy matching overloads

## 📃 Motivating Example

[TS playground](https://www.typescriptlang.org/play?ts=4.9.4#code/JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQFA0wCeYWcAQlMgHYAmAPACoAaOP2QBzOFgAeMLD3SoYUYJzEA+OAF4RcAGRwA3nAD6xmOIBcI8XAC+AbjrTIsOI2ZwAqp2ABHAK5YAHIQ3FgAktxabBw8vIrKqsJk3n6BIWGRZGqOztDw7iypAVgAotxiEVHa7Fx8CSpiycWB5ZVZOXSFcAAiwKiQqCzaABQAlFoaAG4QwNyONCqyUAR4LADyAEZDUFMsBjRwcCOFVmScoVhkwv4+JZFWLcGXkcJYADZYIHIwVqWf304MDGVj6AwgQ0cRxOTCwZywFSuNzugQeXhRZURr0kAJ+f1xQJBvX6gywjlsdFwEE4ijg+Ck0WweBgADpcJRkLIAMLU2QyXhbHZ7NQjcaTY4TTTTWZRAAMYwWeVcBFu+GA1Lg-iG2FQwAAXlgRoc4CzTQBtQrItJVYSUAgAXQsxqOAB84BbYWcLmFrpqMWinhkbXA7VYmfgWdgCFsAFZYfC8f5fH5qe3OuBuj3MeGI323a0BjFtYOhzBUVlR2PxmCJgkwVM0CYHI5UmnwCDbLC7YZl5ksrVYHlA6QwEb0sZ0I7h1kDgAyyAYEH8MFKBAI1dFko0zaOdOptI+yaB0TtbP8UEoQIAhFDd5QYOfOHAO0LDZa-QXuG86wq4AB6P83AAC36OBQNwc9Lxgd4GBQJ8u2IKBjVsYQsywK17i-EMsAIYQXy7PZ7QVGhbCAA)
```ts
import * as React from 'react'

type Brand<T, Tag extends string> = T & { __tag: Tag };

export type UniqueNodeId = Brand<string, 'UniqueNodeId'>;
export type UniqueEdgeId = Brand<string, 'UniqueEdgeId'>;

type Dispose = () => void;

interface Observe {
  (type: 'node', uniqueId: UniqueNodeId, element: Element): Dispose;
  (type: 'edge', uniqueId: UniqueEdgeId, element: Element): Dispose;
}

const ctx = React.createContext<Observe>(() => () => void 0);

export function useResize(
  ...[type, uniqueId, ref]:
    | [type: 'node', uniqueId: UniqueNodeId, ref: React.RefObject<Element>]
    | [type: 'edge', uniqueId: UniqueEdgeId, ref: React.RefObject<Element>]
) {
  const observe = React.useContext(ctx)

  React.useLayoutEffect(() => {
    const element = ref.current!;
    return observe(type, uniqueId, element); // this is currently an error
  }, [type, uniqueId, ref, observe]);
}
```

## 💻 Use Cases

It seems like a natural extension of the dependent parameters improvements that shipped in TS 4.6. Overloads are often at odds with some TS features though (like with conditional types) so I'm not sure if you want to work on improvements related to them. 

The nice thing about overloads is that they don't require extra binding patterns etc to be used - whereas declaring parameters with tuple types pollutes the runtime code and displays differently in the IDE tooltips etc (although sometimes the tooltips act as if the tuple-based signature would be an overloaded one).

Perhaps it would be good to have a documentation page explaining the difference, cons and pros of each approach? It also could suggest which one is better is better in the "modern" TS.

I can somewhat workaround this ([TS playground](https://www.typescriptlang.org/play?ts=4.9.4#code/JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcARFDvmQNwBQdMAnmFnAEJTIB2AJgDwAVADRxByAOZwsADxhY+6VDCjBuEgHxwAvGLgAyOAG84AfVMxJALjGS4AX3p1ZkWHGas4AVW7AAjgCuWAByELxYAJK8OhxcfPzKquqiZD7+QaHhUWQa9C7Q8B5saYFYAKK8EpHRupw8AolqEiklQRVV2bkMRXAAIsCokKhsugAUAJQ6WgBuEMC8TmryUAR4bADyAEbDUNNsRnRwcKOHR3AAdJfIUBKoVqdncAA+cADaWAA2WCAKMDZlXx+3BgoiKNjI3DCWDIogCvlKURsrRCUKiAF0HmcXu9Ab9-rjgaCWFhwVhKtDYfCgojvFTyuT0adxjZ+oMIMN6PYGLgINxlHB8DIYtg8DBzrhKMh5ABhXnyOT8LY7PYaUYTKbHSbaGZzaIABnGTnybgIcPwwF5cACw2wqGAAC8sCcjpdzq9KARRK7KMo0fdHtiPTYRfhztgCFsAFZYfD8AHfX4aImscGQ8Iwq10mnIzLVDEBt5BzBUMXhqMxmBxgkwJPuYmk8kZuHpapIuntPN0SYHI48vnwCDbLC7EbF0Xna1YWXA2QwUaCw0MI4hsWTgAyyCYEACMDKBAIFbVWq0PbOff5nwTwJiHvFASglGBAEJ6I9KDB79w4IPlU7L0CQQuS4fRgRcjnsUR3SwZRXj1NFRBA14AEZ4LgD1RB-Yc9jRRcuSAA)) but the slight problem with this solution is that it requires me to reorder the parameters (to what I think is less intuitive to the caller, in my context). I could use tuples with trailing fixed elements but there is no good runtime way of unpacking such elements that wouldn't require extra set of helpers.