Union of function signatures cannot be invoked because it lacks a call signature

[Arnavion]

Reduced test case:

var foo: ((arg: string) => void) | ((arg: any) => void);
foo(null);

1. With 1.5.3, this compiles fine. With 1.6-beta, this gives error TS2349: Cannot invoke an expression whose type lacks a call signature. null is assignable to both string and any so it should compile.
2. Maybe related - getting quickinfo for foo on the second line does throw an error TypeError: Cannot read property 'flags' of undefined in playground even though it compiles fine with 1.5.3. I didn't try quickinfo on 1.6
3. If foo was ((arg: string) => void) | ((arg: number) => void); (number instead of any in the second signature) then both 1.5.3 and 1.6 give that error, even though again null is assignable to both.

---

For motivation, the original code is https://github.com/Arnavion/libjass/blob/6606413/src/utility/promise.ts#L363 (the error is on handler). It's an implementation of the ES6 promise spec, specifically http://www.ecma-international.org/ecma-262/6.0/#sec-promisereactionjob - handler would be either the fulfilled callback or rejected callback and the argument passed to it would be either the resolution value or the rejection reason accordingly, hence its signature.

(I understand it would be more type-safe to have separate handlers for the two cases with one signature each from the union, but that complicates the implementation slightly.)

[Arnavion]

I guess it has to do with the fact that the union type doesn't contain call signatures unless the signature parameters match exactly in all constituents types 3.11.1. So does that mean the bug was in 1.5.3 to allow it to compile in the first place?

[mhegazy]

This a result from removing the aggressive subtype reduction that was in 1.5.* (see #3823). Now we are not reducing to subtypes, so the type still contain the two signatures. at time when the call resolution happen 3.11.1 takes effect, and no call signatures are found.

This is a breaking change from 1.5.3 (will add it to the docs).

Also related to #3823

[Arnavion]

Does not reducing to a subtype with one signature help prevent any errors?

And is there a way to make this work with 1.6 while still keeping the union type?

[xLama]

@Arnavion

You could use call, apply or bind. I know it´s very ugly but It works.

var foo: ((arg: string) => void) | ((arg: number) => void) = function(a:string):void{alert(a)};
var foo2: ((arg: string) => void) | ((arg: number) => void) = function(a:number):void{alert(a)};

foo.call(this, "a"); // Be careful with "this". It´s a context.
foo2.call(this, 1);  // Be careful with "this". It´s a context.

[Arnavion]

Yeah. Splitting into two handlers is cleaner, so I'll go with that.

[mhegazy]

@Arnavion, the aggressive subtype reduction would causes cause these errors to disappear, but it also caused loss of information from the union type. the fix was to keep the union information as long as possible. Subtype reduction now is only happening on the lever of operators like conditional and Or (see #3823). in this sense something like:

var foo1: ((arg: string) => void)
var foo2:  ((arg: any) => void);

var foo = foo1 || foo2; 
foo(null); // works

[drarmstr]

Looks like we also get this error when both types are derived from the same base class and we try calling a method of the base class. Is that expected as well?

class Base {
    foo() { }
}

class Derived1 extends Base { }
class Derived2 extends Base { }

var spam : Derived1 | Derived2 = ...
spam.foo(); <- error lacking call signature

[mhegazy]

@drarmstr, this should not be an error. i think there is something else going on. also this is an old issue. please file a new one with more information about your code and the version of the compiler you are using.

[RyanCavanaugh]

@drarmstr that code doesn't issue an error when I compile with the latest TypeScript

[drarmstr]

Yeah, the scenario was from a much more complicated code base. If I can get a simpler test case to reproduce then I'll submit a new issue. I switched to using an interface for the common methods, though, and it's been working for me.

On Feb 12, 2016, at 12:23, Ryan Cavanaugh notifications@github.com wrote:

@drarmstr that code doesn't issue an error when I compile with the latest TypeScript

—
Reply to this email directly or view it on GitHub.

[bjnsn]

Hmmm. A scenario like following still throws this error in 1.8.7, which doesn't seem like it should:

var arr:(Array<number>|Array<string>) = [5];
arr.map(String);

However if making it more permissive:

var arr:Array<number|string> = [5];
arr.map(String);

or restricted:

var arr:Array<number> = [5];
arr.map(String);

fixes the error.