Narrowing of `instanceof` inconsistent with that of`typeof` for Function types

[jcao219]

https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#narrowing-functions-now-intersects--object-and-unconstrained-generic-type-parameters

TypeScript Version: 3.8.3

Search Terms:
narrowing instanceof
narrowing functions

Expected behavior:

instanceof should match typeof (intersect over unconstrained T)

Actual behavior:

divergence

Related Issues:

Code

function callOrNot1<T>(x: T | (() => T)): T {
  return typeof x === "function" ? /* correctly errors here */ x() : x;
}

function callOrNot2<T>(valOrFunc: T | (() => T)): T {
  return valOrFunc instanceof Function ? valOrFunc() : valOrFunc;
}

callOrNot2<() => string>(() => "")() // compiles, fails at runtime

Output

"use strict";
function callOrNot1(valOrFunc) {
    return typeof valOrFunc === "function" ? valOrFunc() : valOrFunc;
}
function callOrNot2(valOrFunc) {
    return valOrFunc instanceof Function ? valOrFunc() : valOrFunc;
}
callOrNot2(() => "")();

Compiler Options

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}

Playground Link: Provided

[RyanCavanaugh]

I don't see any error in the first example?

Anyway you should write this as

type Returnish<T> = T extends () => infer U ? U : T;

function callOrNot1<T>(x: T): Returnish<T> {
  return typeof x === "function" ? /* correctly errors here */ x() : x;
}

function callOrNot2<T>(valOrFunc: T): Returnish<T> {
  return valOrFunc instanceof Function ? valOrFunc() : valOrFunc;
}

callOrNot2<() => string>(() => "")() 

[jgbpercy]

Hmm, @RyanCavanaugh when I open the playground link in the issue I definitely get a TypeScript error on line 2, and not one on line 6, due to a difference in the narrowing behavior between typeof x === 'function' and x instanceof Function.

There may be a semantic difference between typeof and instanceof at JS runtime, or some design decision/limitation with TS, that justifies that difference, However, it does seem odd that callOrNot2 does typecheck despite producing a runtime error, while callOrNot1 produces a compile-time error.

Having said that, the error in callOrNot1 is not actually "correct". The error TS gives is that (T & Function) is not callable. The actual type safety issue here is that T might be a function, and therefore calling something with type T would not (necessarily) return something of type T. Again, there may be some limitation of TS that makes it impossible/impractical/unwanted to catch that kind of error in this case (it seems likely here tbh), but I'm just pointing out that TS isn't catching the actual issue with callOrNot1.*

Having said that, T & Function is callable if you have some value of just that type. But if you have a value that is T & Function in a union with some other type, even if that other type is callable then the union is not. This is demonstrated in this playground link

At the risk of repeating myself, I'm aware this may be an acceptable limitation of TS. I would think any code that ends up with anything typed (T & Function) is probably a bit funky in the first place, and calling union types tends to be something I assume wont work in general.

tl;dr there are three potential issues:

• typeof x === 'function and x instance of Function narrow types differently.
• TS does not catch that if it knows that a value of type T | (() => T) is a function, then T might be a function type that does not return T
• Even though (T & Function) is callable, and SomeCallableType is callable, (T & Function) | SomeCallableType is not callable.

I doubt that the latter two are actually novel issues that you'd want to fix, but if they are then let me know and I can raise them separately. For the first issue it would be good to know if that's expected behavior?

*(edit: on playing around with this further it seems almost impossible to write legit code that is affected by this T | (() => T) soundness issue, rather than code that is deliberately trying to trick TS by putting dumb stuff in generic params - if you actually just let TS infer the generic params it always does the right thing I think. Although that does still leave the fact that technically both callOrNot1 and callOrNot2 are unsound and not showing a type error relevant to that lack of soundness. I believe this is one of those cases where it really doesn't matter though)

[jcao219]

Hi Ryan, thanks for your rapid response.

@jgbpercy is right, the playground link should show an error on line 2.

Is the difference in typeof and instanceof intentional?

[RyanCavanaugh]

typeof and instanceof behave differently and should; they are different operations. Object.create(Function.prototype) is instanceof Function but its typeof is "object", for example.

You should never, ever, ever write a type like T | (() => T). We don't have any way to prevent this, but it's always going to create problems to write any type of the form T | SomeOtherForm<T>.

Calling union types is tricky; see other issues on this. Going through Function goes down a special code path called "untyped function call" and it's very much a special case.

[jcao219]

I see! I've always suspected that Function is a special code path.

You should never, ever, ever write a type like T | (() => T). We don't have any way to prevent this, but it's always going to create problems to write any type of the form T | SomeOtherForm<T>.

Does that mean T | Array<T> is a problematic type?

After all, ReadonlyArray<T> can be thought of as (x: index) => T

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.