Proposal: Expand `inferFromTypeArguments()` candidates to include heritage elements

[Renegade334]

🔍 Search Terms

infer heritage extends

✅ 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

The compiler's stepwise approach to type inference includes a check for the case where it's inferring type parameters, and the inference source and inference target reference the same type. If so, a call to inferFromTypeArguments() grabs the types directly from the inference target. A silly example:

interface Nothing<T> {}
declare function inferFromNothing<T>(arg: Nothing<T>): T;

declare const n: Nothing<boolean>;
inferFromNothing(n); // returns `boolean`

Even though there's absolutely zilch in the Nothing interface from which to infer T, the compiler identifies that the type of e and the type of arg are both references to the generic type Nothing, and infers the type parameter directly via inferFromTypeArguments().

The same does not apply to heritage types, though. Following on from the same example:

interface AlsoNothing<T> extends Nothing<T> {}

declare const a: AlsoNothing<boolean>;
inferFromNothing(a); // returns `unknown`

The type of a and the type of arg are no longer TypeReferences to the same type, so the checker doesn't call inferFromTypeArguments() and goes down its alternative inference strategies. In this instance, inferFromObjectTypes() is chosen, but this obviously has nothing to work with, and yields unknown.

These are nonsense examples, but it's not difficult to construct more complex generic object types where the type parameter doesn't appear as a straightforward property type or return type, which can cause inferFromObjectTypes() to fail. (See the motivating example below for where this originally arose.)

Would it be possible for the compiler to traverse the heritage elements of the inference source, and infer the type parameters directly via inferFromTypeArguments() if it finds the target among those elements?

📃 Motivating Example

The case that prompted this question was related to attempting to infer a type parameter from the EventEmitter class in @types/node.

A simplified reduction:

type EventMap<T> = Record<keyof T, unknown[]>;
declare function inferEventMap<T extends EventMap<T>>(emitter: EventEmitter<T>): T;

interface MyEventMap { event1: [boolean]; event2: [string] }

declare class EventEmitter<Events extends EventMap<Events>> {
    on<T extends string | symbol>(eventName: T, listener: T extends keyof Events ? (...args: Events[T]) => void : (...args: any[]) => void): this;
    emit<T extends string | symbol>(eventName: T, ...args: T extends keyof Events ? Events[T] : any[]): boolean;
    // ...
    eventNames(): Array<string | symbol> & Array<keyof Events>;
}
declare class DerivedEventEmitter<Events extends EventMap<Events>> extends EventEmitter<Events> {}

const baseEventEmitter = new EventEmitter<MyEventMap>();
inferEventMap(baseEventEmitter); // returns MyEventMap

const derivedEventEmitter = new DerivedEventEmitter<MyEventMap>();
inferEventMap(derivedEventEmitter); // returns { event1: any; event2: any }

This is one of those cases where inferFromObjectTypes() just doesn't have enough information to infer the type accurately, even though the type checker should have enough information to identify that the type of derivedEventEmitter is a heritage descendent of EventEmitter.

💻 Use Cases

Hopefully covered above.

[RyanCavanaugh]

It's not really clear how this generalizes beyond the very straightforward cases of a single type parameter in the same position with the same name with no other arguments.

For example, you could easily have

interface Base<A> { }
interface T1<X, Y> extends Base<string>, Base<Y | number>, Base<[X, Y]>, Base<X & number> { }

where it's not really obvious what you'd do when inferring T1<string, number> to Base<?>. At best you'd have to create a whole new set of nonstructural rules.

It's easy to say "well just don't support that", but the core complaint here is that something works when it's simple and fails when it's complex, and just shifting the line around what constitutes "simple" and what constitutes "complex" muddies the water even further.

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

[Syjalo]

As a workaround, you can declare a property using symbol as the key and the generic type as the value

interface Nothing<T> {
	[type: symbol]: T
}

interface AlsoNothing<T> extends Nothing<T> {}

declare function inferFromNothing<T>(arg: Nothing<T>): T;
declare const a: AlsoNothing<boolean>;

inferFromNothing(a); // returns `boolean`

However, I'm not sure about any edge cases if you'll use it in the event emitter class

[ckohen]

es private class fields also work, and actually have a similar behavior in typescript to the base generic because they're nearly inacessible except for within the class definition and when implementing a class as an interface.

For example, you could easily have

interface Base<A> { }
interface T1<X, Y> extends Base<string>, Base<Y | number>, Base<[X, Y]>, Base<X & number> { }

It's not easy at all. As soon as you use that type parameter anywhere within the base interface then T1 is illegal.

Furher, inferFromTypeArgument should not be looking at the last interface unless it needs to, it should understand the inheritance chain and be able to look at whatever generic was passed to the requested interface, if that generic is itself generic from the current interface, then and only then should it observe the argument to the current interface.