Repository: TypeScript
Issue: Support for co-dependently conditionally typed arguments
Labels: Suggestion,Needs Proposal

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

- "co dependent arguments"
- "co-dependent arguments"
- "codependent arguments"
- "codependently arguments"
- "codependently typed arguments"

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

It should be easier to conditionally type a function argument based on the type/value (in the case of enums / string literal types) of a previous argument in the function. Having a more specific way to do this than currently possible should improve editor intelligence and performance. 

<!-- A summary of what you'd like to see added or changed -->

## Use Cases

It is quite common to have an API where the type of the second argument depends on the type and/or value of the first. For example, take a look at the following JavaScript code. (It's a fairly trivial example, but it should illustrate the use case.

```js
function reducer(actionType, args) {
    switch (actionType) {
      case "add":
        console.log(args.a + args.b);
        break;

      case "concat":
        console.log(args.firstArr.concat(args.secondArr));
        break;
    }
}

reducer("add", { a: 1, b: 3 }); // 4
reducer("concat", { firstArr: [1,2], secondArr: [3, 4] }); // [1,2,3,4]
```

It is currently possible to type this, but it is extremely convulted and the editor somewhat struggles to understand this at the call site. This method is based on the fantastic article over at https://artsy.github.io/blog/2018/11/21/conditional-types-in-typescript/

```ts
enum ActionTypeEnum {
  add,
  concat
}

type Action =
  | { type: ActionTypeEnum.add, a: number, b: number }
  | { type: ActionTypeEnum.concat, firstArr: any[], secondArr: any[] };

type ActionType = Action["type"];

type ExcludeTypeKey<K> = K extends "type" ? never : K

type ExcludeTypeField<A> = { [K in ExcludeTypeKey<keyof A>]: A[K] }

type ExtractActionParameters<A, T> = A extends { type: T }
    ? ExcludeTypeField<A>
  : never

function reducer<T extends ActionType>(actionType: T, args: ExtractActionParameters<Action, T>) {
  const properlyTypedArgs = { ...args, type: actionType } as Action;

    switch (properlyTypedArgs.type) {
      case ActionTypeEnum.add:
        console.log(properlyTypedArgs.a + properlyTypedArgs.b);
        break;

      case ActionTypeEnum.concat:
        console.log(properlyTypedArgs.firstArr.concat(properlyTypedArgs.secondArr));
        break;
    }
}

reducer(ActionTypeEnum.add, { a: 1, b: 3 }); // 4
reducer(ActionTypeEnum.concat, { firstArr: [1, 2], secondArr: [3, 4] }); // [1,2,3,4]
```

There are four main issues with this approach.

The first, fairly obvious one, is that for the type checker to understand that type of args inside the switch, we're having to merge the two arguments into a single object, cast it, and then switch based on that:

```ts
const properlyTypedArgs = { ...args, type: actionType } as Action;
```

This is an example of the type system leaking into the emitted javascript and is arguably inefficient. 

The second is that the editor doesn't really understand what's going on. It understands enough to tell you you've made an error when the type check doesn't validate but also doesn't understand well enough to properly autocomplete. The error could also be easier to understand. See below. 

![image](https://user-images.githubusercontent.com/719814/71518037-abca4c80-28a8-11ea-8c45-32b535612836.png)

![image](https://user-images.githubusercontent.com/719814/71518048-b4bb1e00-28a8-11ea-8fa8-3e39f8a4821d.png)

See above how it's suggesting firstArr and secondArr as fields in the second object, even though including them fails the type checker. The only suggestions should be a & b. 

The third issue is that it's entirely undiscoverable for all but the most advanced in TypeScript. This is a semi-common use case, and I had no idea how to properly type it. Without this singular article detailing this approach, I never would have discovered it. This should be built into the language to fix this.

Fourthly, and similarly, it's very difficult to read and understand unless you really, really understand generics. I am sure that somebody smarter than I would be able to come up with a more expressive way of detailing the co-dependence of these two types. 


<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

I think I've properly explained this in the use case above. 

<!-- Show how this would be used and what the behavior would be -->

## 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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).