Generic enumerated type parameter narrowing (conditional types)

Search Terms

conditional type inference enum enumerated narrowing branching generic parameter type guard

Suggestion

Improve inference / narrowing for a generic type parameter and a related conditional type. I saw another closed-wontfix issue requesting generic parameter type guards, but a type guard should not be necessary for this case, since the possible values for the generic are enumerated.

Use Cases

(Names have been changed and simplified) I have a method that takes a KeyType (enumerated) and a KeyValue with type conditionally based on the enumerated KeyType.
Depending on the KeyType value, the code calls method(s) specific to that type.

The TS compiler is unable to tell that after I have checked the enumerated KeyType, the type of the KeyValue (string, number, etc) is known and should be able to be passed to a function that only accepts that specific KeyValue type.

Examples

const enum TypeEnum {
	String = "string",
	Number = "number",
	Tuple = "tuple"
}
// The issue also occurs with
// type TypeEnum = "string" | "number" | "tuple"

interface KeyTuple { key1: string; key2: number; }

type KeyForTypeEnum<T extends TypeEnum> 
	= T extends TypeEnum.String ? string
	: T extends TypeEnum.Number ? number
	: T extends TypeEnum.Tuple ? KeyTuple
	: never;


class DoSomethingWithKeys {	
	doSomethingSwitch<TType extends TypeEnum>(type: TType, key: KeyForTypeEnum<TType>) {
		switch (type) {
			case TypeEnum.String: {
				this.doSomethingWithString(key);
				break;
			}
			case TypeEnum.Number: {
				this.doSomethingWithNumber(key);
				break;
			}
			case TypeEnum.Tuple: {
				this.doSomethingWithTuple(key);
				break;
			}
		}
	}

	doSomethingIf<TType extends TypeEnum>(type: TType, key: KeyForTypeEnum<TType>) {
		if (type === TypeEnum.String) {
			this.doSomethingWithString(key);
		}
		else if (type === TypeEnum.Number) {
			this.doSomethingWithNumber(key);
		}
		else if (type === TypeEnum.Tuple) {
			this.doSomethingWithTuple(key);
		}
	}	

	private doSomethingWithString(key: string) {

	}

	private doSomethingWithNumber(key: number) {

	}

	private doSomethingWithTuple(key: KeyTuple) {

	}
}

This should compile without errors if TS was able to tell that the switch statements or equality checks limited the possible type of the other property.

I lose a lot of the benefits of TS if I have to cast the value to something else. especially if I have to cast as any as KeyForTypeEnum<TType> as has happened in my current codebase.

If I’m doing something wrong or if there’s already a way to handle this, please let me know.

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. new expression-level syntax)

[JakeTunaley]

This would be really useful for typing addEventListener patterns. Here’s a sample of real-world code where I ran into this issue:

type FileEvent = 'read' | 'write' | 'delete';

type FileEventListener<T extends FileEvent, R, W> =
    T extends 'read' ? (file: File<R, W>, data: R) => void :
    T extends 'write' ? (file: File<R, W>, data: W) => void :
    T extends 'delete' ? (file: File<R, W>) => void :
    never;

function isReadEvent (evt: FileEvent): evt is 'read' {
    return evt === 'read';
}

class File<R, W> {
    // Implementation omitted for brevity

    public addEventListener<T extends FileEvent> (evt: T, listener: FileEventListener<T, R, W>): void {
        if (evt === 'read') {
            // evt: T extends EventType (expecting "read")
            // listener: EventListener<T, R, W> (expecting (data: R) => void)
        }
        if (isReadEvent(evt)) {
            // evt: T & "read" (expecting "read")
            // listener: EventListener<T, R, W> (expecing "write")
        }
    }
}

[krryan]

Seems related to #21879, and possibly #20375, which are pretty high priorities in my mind, too. Absolutely agreed that we really want something like this to be possible. A common use-case in our code is mapping functions, that take a union and map each possible value in the union to the corresponding value in another union. As an example, a function that maps '1' | '2' | '3' to 1 | 2 | 3. You can write a conditional type for this with

type CorrespondingNumeralOf<Char extends '1' | '2' | '3'> =
    Char extends '1' ? 1 :
    Char extends '2' ? 2 :
    Char extends '3' ? 3 :
    never;

function mapCharToNumeral<Char extends '1' | '2' | '3'>(char: Char): CorrespondingNumeralOf<Char> {
    switch (char) {
        case '1': return 1;
        case '2': return 2;
        case '3': return 3;
        default: impossible(char);
    }
}

/**
 * Ensures complete case-coverage since it mandates a never value.
 * In our implementation, throws an error noting what took on an impossible value,
 * in case of discrepancies between compile-time expectations and run-time reality.
 */
declare function impossible(_: never): never;

But this runs into a couple of problems: TS won’t narrow Char, TS won’t recognize 1 as CorrespondingNumeralOf<Char> in case '1'.

There really ought to be a type-safe way to write these kinds of functions, seeing as there is a type-safe way to describe them.

(And in case anyone thinks function overloads are a solution here, keep in mind that those aren’t really any more type-safe than just using casting here, and in any event, those lack the ability to handle arbitrary subsets of the first union and map them to the corresponding subset of the second union. Not too bad when looking at three cases, but I recently wrote something very much like this that handled 28 cases.)