Generic enumerated type parameter narrowing (conditional types)

[krisdages]

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)

[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.)

[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")
        }
    }
}

[mattmccutchen]

After reading #27808, I realized that the original example is unsound. A caller can just do:

new DoSomethingWithKeys().doSomethingSwitch<TypeEnum>(TypeEnum.String, 42);

We'd need to express somehow that TType must be (in this scenario) a singleton type. Compare to #25879.

[jack-williams]

I remember thinking about this when a thread regarding multiple use type parameters came up. Perhaps something like: uniform types. Types inhabited only by values that behave uniformly under operations such as typeof.

We write T*, where * is a predicate on types that holds when:

• for all x, y in T. typeof x === typeof y.

So string* is valid, so is number*, but not string | number.

Example:

declare function assert<T*>(x: T, y: T): boolean;
assert(true,false) // ok
assert(1,false) // not ok

declare function assertWide<T>(x: T, y: T): boolean;
assertWide(true,false) // ok
assertWide(1,false) // ok, T = number | boolean

It might even be possible to specify the operation, so we could include equality for enums.
We write T=, such that

• for all x, y in T. x === y.

new DoSomethingWithKeys().doSomethingSwitch< TypeEnum= >(TypeEnum.String, 42);
// invalid, TypeEnum does not satisfy predicate =

new DoSomethingWithKeys().doSomethingSwitch< TypeEnum.String= >(TypeEnum.String, "foo");
//ok

[jack-williams]

I have a very experimental PR that is capable of type-checking the original example: #30284

[tadhgmister]

Can get around this by using an interface to map strings to corresponding types instead of a ternary chain. Not sure why generic type that is constrained by a union doesn't narrow though, but using a temporary variable can get around that as well:

interface Numerals {
    '1': 1;   '2': 2;   '3': 3;
}
type CorrespondingNumeralOf<Char extends keyof Numerals> = Numerals[Char];

function mapCharToNumeral<Char extends keyof Numerals>(char: Char): CorrespondingNumeralOf<Char> {
    const c: keyof Numerals = char;
    switch (c) {
        case '1': return 1;
        case '2': return 2;
        case '3': return 3;
        default: impossible(c);
    }
}

For the original case it's a little more complicated, to narrow one variable type needs a way to relate to the type of the other, which means we have to have a variable that actually implements this pseudo interface:

const enum TypeEnum {
    String = 'string', Number = 'number', Tuple = 'tuple'
}
interface KeyTuple { key1: string; key2: number; }

interface Mapping {
    // use this for lookup instead of ternary chain.
    [TypeEnum.String]: string;
    [TypeEnum.Number]: number;
    [TypeEnum.Tuple]: KeyTuple;
}
type KeyForTypeEnum<T extends TypeEnum> = Mapping[T];

class DoSomethingWithKeys {
    public doSomethingSwitch<TType extends TypeEnum>(type: TType, key: KeyForTypeEnum<TType>) {
        // will have one of the fields viable, this way when we get a value from part
        // it will be type checked
        const part: Partial<Mapping> = { [type]: key };
        const typeAlias: TypeEnum = type;
        switch (typeAlias) {
            case TypeEnum.String: {
                type;
                this.doSomethingWithString(part[typeAlias]);
                break;
            }
            case TypeEnum.Number: {
                this.doSomethingWithNumber(part[typeAlias]);
                break;
            }
            case TypeEnum.Tuple: {
                this.doSomethingWithTuple(part[typeAlias]);
                break;
            }
            default: {
                impossible(typeAlias);
            }
        }
    }
    private doSomethingWithString(key: string) {}
    private doSomethingWithNumber(key: number) {}
    private doSomethingWithTuple(key: KeyTuple) {}
}