Bug Report

🔎 Search Terms

generic method union type

🕗 Version & Regression Information

• This changed between versions 4.1.5 and 4.2.3

⏯ Playground Link

Playground link with relevant code

💻 Code

class Visitor1 implements IAVisitor<string>, IBVisitor<number>, ICVisitor<boolean> {
    visitA(): string {
        return "hello";
    }

    visitB(): number {
        return 42;
    }

    visitC(array: (A|B)[]): boolean {
        const result: (string|number)[] = array.map(item => item.accept(this));
        return true;
    }
}

🙁 Actual behavior

In Visitor1#visitC, in the call to accept there is an error on this: Argument of type 'this' is not assignable to parameter of type 'IAVisitor<string> & IBVisitor<string>'.

The Typescript compiler seems to arbitrarily choose the first generic type of the first interface implemented by Visitor1 to infer a type T on a single aggregated function type for item.accept. This is simply incorrect.

In TS version 4.1.5, the Typscript compiler refused to aggregate the function types at all: This expression is not callable. Each member of the union type '(<T>(visitor: IAVisitor<T>) => T) | (<T>(visitor: IBVisitor<T>) => T)' has signatures, but none of those signatures are compatible with each other.

So it seems that in version 4.2.3 some kind of incorrect type logic was applied to aggregate the union of function types.

🙂 Expected behavior

The JavaScript semantics of this call will use the accept method of the respective instance, returning string or number respectively, and the call to map will return type (string | number)[]. So, the type inferred on accept should be an overloaded function or a union of function types, whose members are generated by applying type inference on the argument this in a distributive manner:

• Before type inference:

item.accept: (<T>(visitor: IAVisitor<T>) => T) | (<T>(visitor: IBVisitor<T>) => T)

where keeping in mind that generic T is independently free in each union member.

• The type of this should be treated as an invariant in the type inference, e.g.:

this: IAVisitor<string> & IBVisitor<number> & ICVisitor<boolean>

• The proper way to infer the concrete type of item.accept is to distribute the type of this over each generic member of item.accept, then unify the parameter type with the argument type, over the generic parameters. After type inference:

item.accept: (<T extends string>(visitor: IAVisitor<string>) => string) | (<T extends number>(visitor: IBVisitor<number>) => number)

• The type of this obviously distributes over the union type of item.accept to produce the return type string | number. This matches the JavaScript semantics and the actual return type.

• The code in Visitor2 shows that if we explicitly narrow the type of item before calling accept, the aggregated return type is as expected. Having to explicitly narrow the types this way defeats the purpose of using the visitor pattern.

Simplifying the union of function types into a single function type is problematic when generics are involed:

I guess if you wanted to simplify the union type of item.accept, a naive attempt would look like

item.accept: <T extends string | number>(visitor: IAVisitor<string> & IBVisitor<number>) => string | number

but this might be problematic if the generic functions accept had different numbers of generic arguments. Technically each generic parameter in the union needs to become a separate generic parameter on the aggregated function type and unified independently:

item.accept: <T0 extends string, T1 extends number>(visitor: IAVisitor<string> & IBVisitor<number>) => string | number

so it may be better to avoid this type of simplification.