Type Inference on function arguments

[rtpg]

TypeScript Version:
2.3.0

Code

function f(x: number){
   return x;
}

function g(x){ return x};

function h(x){ return f(x); };

Expected behavior:
I would expect the inferred type of g to be (x:any)=>any, and the infered type of h to be (x:number) => number (due to the restrictions placed by the call of f)

When compiling with noImplicitAny, I would only expect an error on g, not on h

Actual behavior:
Running tsc --declaration on this snippet gives me:

declare function f(x: number): number;
declare function g(x: any): any;
declare function h(x: any): number;

the x argument on h does not seem to use the f(x) call to tighten the definition.

Considering the simplicity of the example, I imagine I might be missing an important detail in the type system that makes this the proper inference result, but I haven't figured it out yet.

[vkurchatkin]

Typescript never infers function arguments. So, unless you specify them, they are always going to be any

[rtpg]

Right, but is there a reason for them not to? It feels within reach, and not much different than other kinds of inference

[RyanCavanaugh]

It's very different and very complex. When you consider that any of those calls might have union types or overloaded signatures in their parameter types, it's not even clear what should happen for a single call (let alone multiple calls):

declare function f(n: number, s: string): void;
declare function f(s: string, n: number): void;
declare function f(x: boolean, y: boolean): void;

// g(a: ??, b: ??)
function g(a, b) {
    f(a, b);
}

Current inference is very straightforward: types almost always come from initializers or contextual types. Both of those are static one-pass things that you can follow back as a human. Trying to do inference from call sites looks neat in simple examples but can make it very hard to trace errors to their actual sources, and is unscalable to large programs.

[bcherny]

@RyanCavanaugh Is there some sort of design doc for how TypeScript's type inferer works, and what kind of system it's based on?

Eg. I believe a Hindley-Milner inferer would give a: boolean | number | string, b: boolean | number | string for your example. This seems to be @rtpg's expected behavior.

[RyanCavanaugh]

That type would be incorrect because it allows string, string as an argument list.

The TypeScript spec https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md defines how inference works at each declaration site. There is no global inference algorithm to describe because TS doesn't do global inference ala H-M.

[bcherny]

I see. So we would have to infer the same signature as f() itself.

What was the rationale for not using global inference? Is it that TS tries to do the best it can in the absence of a sound type system?

[RyanCavanaugh]

Soundness is mostly orthogonal.

I think the general problem is that global type inference in an imperative language is much more expensive than in a functional language. The difference between OCaml and Scala is instructive here. There's a reason Flow limits its "global" inference to file boundaries - it's not practical to scale up global inference to an entire large JS program.

Global inference also doesn't detect a lot of errors in imperative programs. Consider this code, which is a totally legal JavaScript program:

var x = { kind: 'a' };
if (Math.random() > 0.5) {
  x = { knd: 'b' };
}
x.type = "foo";

Flow says this program has one error, TypeScript says this program has two errors, H-M I believe says this program has zero errors (x ends up with as { kind: string, type: string } | { knd: string, type: string }). Who's right? I think one vs two is arguable, but it's almost certainly not zero (despite being a program that does not throw exceptions or observably mistype a value).

Global inference is also bad at producing sane errors

function doSomething(x) {
  console.log(x.y);
}

var arr = [{x: 100, y: 100}, {x: 200, z: 200}];
doSomething(arr.pop());

Flow helpfully says

2:   x.y;
       ^ property `y`. Property not found in
2:   x.y;
     ^ object literal

which does not help you at all at figuring out the typo elsewhere in the program.

So basically any sane programmer is going to put type annotations on parameters anyway (since you must at module boundaries anyway, and you must if you want sane errors). Once you have type annotations on type parameters, local inference is sufficient for the vast majority of cases.

[bcherny]

@RyanCavanaugh As always, thank you for the detailed and well thought out responses.

I think one vs two is arguable, but it's almost certainly not zero (despite being a program that does not throw exceptions or observably mistype a value).

This seems to be a philosophical question with tradeoffs.

1-2 errors is restrictive because it requires me to explicitly declare a type with 2 optional members before my program will compile, but as you said, the benefit is errors are local, which makes debugging fast and pleasant.

0 errors is more correct (the union type should be handled downstream, and if it's not, the compiler can warn about an unexhaustive match or possibly missing member), but the drawback is nonlocal errors when you're wondering "why is the compiler saying this a union type?".

[From an earlier comment] Trying to do inference from call sites looks neat in simple examples but can make it very hard to trace errors to their actual sources, and is unscalable to large programs.

How do Haskell, OCaml, and Elm engineers manage to use their languages at scale? From this SO post, it sounds like those languages are more restrictive than JS in what they can express (eg. no class extensions), which makes H-M usable.

[rtpg]

@RyanCavanaugh relative to your initial example, where you call f (with 3 different type definitions):

I feel like in that case it would be reasonable to have this generate 3 different types for g. Maybe this leads to combinatorial explosion of types in some cases, but I imagine in most cases it won't because in real world examples function wrappers exist to make more specific calls to the inner functions.

TypeScript already has the control flow analysis in place to keep track of when x:string|number ends up actually being string or number, so it feels like you could do some of this work in reverse? Obviously easier said than done.

For full context: I really want to use noImplicitAny, but our codebase includes a lot of wrapper functions of the form function(a){ return g(a,'some_literal')}, and these end up being any. If we have to explicitly declare the type signatures on all of these it adds a lot of busy work and makes the "strict type" pitch that much harder.

Is it not possible to do local inference based on the function body (that is to say: ignoring the function's calling context)?

Bringing back the flow example (which I agree is weird):

function doSomething(x) {
  console.log(x.y);
}

var arr = [{x: 100, y: 100}, {x: 200, z: 200}];
doSomething(arr.pop());

I feel like the "proper" set of errors that should happen would be:

• doSomething gets an inferred type of (x:{y: any}):void
• arr is a little weird, so two possibilities:
  • arr requires an explicit type, given that the dictionaries are very different
  • arr gets a type like ({x:number, y:number} | {x:number, z:number})[]
• In the case of the union type, doSomething(arr.pop()) fails because the union type doesn't align with the type of {x: any}

I realize "well let's just have giant types" feels very hand-wavy...

I think a reasonable alternative would be "try to deduce argument types from usage within the function, and opt for any if all collected possibilities in the function body have any inconsistencies (for example number and string, but not {x:string, y:string} and {x:string}, which ends up with {x:string, y:string}). This would allow for small anonymous functions to get the "obvious" typing while still requiring to be explicit in cases where there's no good answer.

Purescript (and its record types) has some functionality close to this, so inference works pretty well (though you tend to lose type aliases. This is already the case in TypeScript though)

[aluanhaddad]

So basically any sane programmer is going to put type annotations on parameters anyway (since you must at module boundaries anyway, and you must if you want sane errors). Once you have type annotations on type parameters, local inference is sufficient for the vast majority of cases.

I fully agree with this. The reasoning is very straightforward. It is also worth noting that no type annotations need be placed on the parameters declared by function literals passed as callback or assigned to an already typed local.

I am glad that you referenced Scala because it also has essentially the same requirements for where type annotations must be placed as TypeScript does under --noImplicitAny, they are only required on the parameters of functions that are not callbacks and not a value assigned to a typed local.

You also mention OCaml which while it has much stronger type inference than TypeScript or Scala, exhibits some very counterintuitive behavior with respect to inference of function parameter types
Consider this OCaml:

let square x = x * x 
let i = square 4
(* 16 *)
let f = square 4.0
(* Error: This expression has type float but an expression was expected of type int *)

[bcherny]

@aluanhaddad Nit: your example is an Ocamlism, and is not a statement about H-M in general. Eg. Haskell infers x as Num, which compiles:

let square x = x * x
let i = square 4 -- 16
let f = square 4.0 -- 16.0

[vkurchatkin]

@bcherny well, this works in Haskell because of type classes, but they are not a part of H-M