Type union narrowing upon index access

[sabberworm]

🔍 Search Terms

"type union narrowing on multiple properties", "type dependencies", "narrowing indexed", "narrowing argument"

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Notice: It’s likely this request has been raised before and I wasn’t using the right search terms. Apologies in advance.

Using type unions and dynamic property access extensively, I have come across the following situation a few times already: There is a discriminating element in the type union that could be used to index a different type that references the corresponding union component. TypeScript could know whether the result from the property access and the union type are structurally related and allow the access. However, as it stands, it needs a little help in form of an explicit conditional (see example below).

📃 Motivating Example

https://www.typescriptlang.org/play?ts=5.3.2#code/JYOwLgpgTgZghgYwgAgPICMBWyDeAoZZOALmQGcwpQBzAbgOXVJAFcBbdaewsiMAQQAUJcpRoBKUgDcA9sAAm3cnwBCgpslYdok5LIX0AvnjABPAA4oACjLJlg6ADYR+CJHZlQyyALwMAPrjmUDLmpADkcOEANHpwjiwQpBRUINSxvGCQUBGZ-OHGhIE4waER6DFxCUma7JxQGXzZuaoF9HgwLCAIYMAyIMpgViHmgjJYpBiYsWCkNnYOzq7uZJ5k4rgMwDCCYAB0pea+Pj7IkeEb+ISE45gA2vuHALq+yPtS8YlKhsgQjryba7IW4PA4jF6nd6fCDfPDGTrdXr9QbLCAeKBjCZoLAzOa2exOFxuNGrLyXLY7R4jY6nc7koEg-aZbJPXZ7D7VcTfX7-FBXa6MvbM6CsqGc2HGPBAA

interface Obj {
  a: string;
  b: number;
  setA(a: string): void;
  setB(b: number): void;
}
type PossibleAccessors =
  | {prop: 'a', value: string, setter: 'setA'}
  | {prop: 'b', value: number, setter: 'setB'};

function setProp(obj: Obj, t: PossibleAccessors) {
  if(t.prop === 'a') {
    obj[t.prop] = t.value;
  } else {
    obj[t.prop] = t.value;
  }
}
function setAccessor(obj: Obj, t: PossibleAccessors) {
  if(t.prop === 'a') {
    obj[t.setter](t.value);
  } else {
    obj[t.setter](t.value);
  }
}

In this example, the if…else constructs in the functions setProp and setAccessor are entirely superfluous but currently required for successful compilation.

As it stands, with every component added to the PossibleAccessors union, a new control flow branch has to be added to get the code to compile without type casting.

💻 Use Cases

Currently, I resort to type casting in these situations and I enforce conformability between the unions and the corresponding properties using an intricate set of conditional types. This is brittle as there is no nothing informing me when I have set these types up incorrectly. Even when it works, it makes the compile error happen at a location very different from where the run-time error would be.

It would be a tremendous help if TypeScript could narrow the property access correctly without the user having to insert superfluous constructs.

I.e., the following code should just compile™: https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&allowUnreachableCode=true&allowUnusedLabels=true&exactOptionalPropertyTypes=true&noFallthroughCasesInSwitch=true&noImplicitOverride=true&noPropertyAccessFromIndexSignature=true&ts=5.3.2#code/JYOwLgpgTgZghgYwgAgPICMBWyDeAoZZOALmQGcwpQBzAbgOXVJAFcBbdaewsiMAQQAUJcpRoBKUgDcA9sAAm3cnwBCgpslYdok5LIVLqfIbopUQdBkbBrdWzlHoBfPGACeABxQAFGWTLA6AA2EPwISP4yUGTIALwMAD64HlAyHqQA5HAZADR6cEEsEKRmNHm8YJBQmRX8ucjWVZnWdS6ESTgpaZno9VIFRczsDuV8TcgZFSr1jdDNqhlO9HgwLCAIYMAyIMpg3qkegjJYpBiYeWCkvv6BIWERZFFk4rgMx5gA2mAAdF0eALpxZA-fqFCDOFZrDZbHa1cIQSJQI4nNBYC5XPwBYKheGI56vQjvL7fCpVf6CEEDCDiCFAA

[RyanCavanaugh]

This is already possible, at least for the property side of it:

interface Obj {
  a: string;
  b: number;
  setA(a: string): void;
  setB(b: number): void;
}

type ObjAccessor<K extends keyof Obj> = { prop: K, value: Obj[K] };
;
type PossibleAccessors = ObjAccessor<keyof Obj>;

function setProp<P extends keyof Obj>(obj: Obj, t: ObjAccessor<P>) {
  obj[t.prop] = t.value;
}

declare let obj: Obj;
// OK
setProp(obj, { prop: "a", value: "hello" });
// Error
setProp(obj, { prop: "a", value: 32});

I don't think the "setter" implementation is possible to make check, but you can still represent it in the type system

interface Obj {
  a: string;
  b: number;
  setA(a: string): void;
  setB(b: number): void;
}

type FilterBy<K extends keyof Obj, V> = K extends unknown ? Obj[K] extends (arg: V) => void ? K : never : never;
type ValidSetters<V> = FilterBy<keyof Obj, V>;

type ObjAccessor<K extends keyof Obj> = { prop: K, value: Obj[K], setter: ValidSetters<Obj[K]> };

type PossibleAccessors = ObjAccessor<keyof Obj>;

declare let obj: Obj;
// OK
setProp(obj, { prop: "a", value: "hello", setter: "setA" });
// Error
setProp(obj, { prop: "a", value: "hello", setter: "setB" });

I can't think of a way to analyze your given example that doesn't involve combinatorially exploding the check phase into branches based on every possible constituent of the union, which is definitely not a scalable solution.

[fatcerberus]

This looks like another vote for #30581

[typescript-bot]

This issue has been marked as "Too Complex" and has seen no recent activity. It has been automatically closed for house-keeping purposes.