Arrow function with wrong return type relative to explicit signature does not cause compiler errors.

[brunnerh]

TypeScript Version: 2.8.0-dev.20180206

Search Terms:
wrong return type arrow function
inferred type arrow function

Code

// Does not compile, because the signature does not match the inferred return type.
function test1(value: number): void
{
	return value; // error TS2322: Type 'number' is not assignable to type 'void'.
}

// Does compile, type is not correctly inferred, signature is used.
const test2: (value: number) => void
	= (value: number) => value;

test2(42) + 1; // error TS2365: Operator '+' cannot be applied to types 'void' and '1'.

Expected behavior:

test2 fails to compile because the signature does not match the returned object's type, just as test1 does.

Actual behavior:

test2 compiles and uses the explicit signature without error.

Playground Link: [Link]

Related Issues:
#17505 - About argument inference, rather than return type.

[mhegazy]

The first case is clearly a bug. the compiler alerts you that the declared API does not match your implementation..

The second is different, u are allowed to assign something that is more specific to something that is more general.. for instance, var x: Animal = new Dog() is a valid assignment.. similarly, you can assign something that returns a value to one that does not require a value.. the error is correct, since test2 is declared to return a void. that is the same as const x: Animal = new Dog(); x.bark()

[RyanCavanaugh]

https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void

[brunnerh]

I understand the reasoning here but i slightly disagree about the statement This is the expected and desired behavior.

To take the example from the FAQ:

function doSomething(): number {
    return 42;
}
function callMeMaybe(callback: () => void) {
    callback();
}
callMeMaybe(doSomething);

This does absolutely nothing, since doSomething is a pure function and callMeMaybe ostensibly expects to be passed a function with side effects, as that is the only thing a function with such a signature could achieve.

This feature of allowing that assignment has just brilliantly masked a coding error that could have been avoided.

Personally, i think another strict flag would be great to make this sort of assignment illegal. To reasonably work with such a flag, something like an ignore function would be useful, so you can make the second example work without much hassle:

let items = [1, 2];
callMeMaybe(() => ignore(items.push(3)));

[RyanCavanaugh]

This has been discussed countless times, see #19014, #8240, #8584, #8581, #9603, #8615, #20006, etc