Partial type inference failures with tagged union types

[falsandtru]

Probably an example without the type guard of #13454.

TypeScript Version: master

Code

declare function f<P, R, S>(process: Supervisor.Process<P, R, S> | Supervisor.Process.Call<P, R, S>): void;
namespace Supervisor {
  export type Process<P, R, S> = {
    readonly init: Process.Init<S>;
    readonly call: Process.Call<P, R, S>;
    readonly exit: Process.Exit<S>;
  };
  export namespace Process {
    export type Init<S> = (state: S) => S;
    export type Call<P, R, S> = (param: P, state: S) => [R, S] | PromiseLike<[R, S]>;
    export type Exit<S> = (state: S, reason: any) => void;
  }
}
f<void, void, void>({
  init: s => s,
  call: (p, s) => <[void, void]>[p, s],
  exit: s => void s,
});

Expected behavior:

ok

Actual behavior:

$ node built/local/tsc.js -t es6 index.ts --noImplicitAny
index.ts(16,10): error TS7006: Parameter 'p' implicitly has an 'any' type.
index.ts(16,13): error TS7006: Parameter 's' implicitly has an 'any' type.

[HerringtonDarkholme]

It seems the problem comes from call in Process clashes with call in Function.

Smaller reproduction.

declare function f(process: A | B): void;

type A = {
  call(p: number): void
  brand: number
}
type B = {
  call(p: string): void
  brand: string
}

f({
  brand: 123,
  call(n) {} // any
})

To my best knowledge, compiler will not narrow union type in argument inference, for now.

A better alternative is using overloading.

declare function f<P, R, S>(process: Supervisor.Process<P, R, S>): void;
declare function f<P, R, S>(process: Supervisor.Process.Call<P, R, S>): void;

[falsandtru]

Oh it is a nice workaround! Thanks!

[falsandtru]

I found a problem in this workaround. The overload should be:

declare function f<P, R, S>(process: Supervisor.Process.Call<P, R, S>): void;
declare function f<P, R, S>(process: Supervisor.Process<P, R, S>): void;

details: #13780

[mhegazy]

looks like a duplicate of #13780

[mhegazy]

The contextual type for the function is the union type. the union type property does not have a call signature because they are not identical. see #7294 for more details.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.