Support for co-dependently conditionally typed arguments

Search Terms

• "co dependent arguments"
• "co-dependent arguments"
• "codependent arguments"
• "codependently arguments"
• "codependently typed arguments"

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.

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.

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/

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:

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.

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.

Examples

I think I've properly explained this in the use case above.

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Inizia riproducendo gli esempi di reducer TypeScript e esaminando le carenze indicate relative al controllo degli argomenti dipendenti, al narrowing, al completamento automatico e ai messaggi di errore. Il lavoro sarà considerato completato quando saranno disponibili un design del linguaggio concreto e concordato per questa funzionalità e un comportamento convalidato per i casi add e concat.