This project is read-only.

The type inference mechanism is available in tcs,js?

Topics: General
Oct 3, 2012 at 4:02 PM

I am trying to find extension points in the typescript compiler and i couldn't figure out a place where type information for specific nodes is calculated.

Is this type inference feature implemented in the Language Service only?


Oct 5, 2012 at 7:27 PM

Thanks for the question.  We perform type inference for both command-line compiles as well as within the language service.  (In fact, the language service sits atop the compiler itself - typescript.js.)

For type definitions as well as annotated constructs, types are calculated during the type collection and binding phases (see typeCollection.ts and binder.ts).  Once the "known" types are assigned to symbols, inferencing is interleaved with the typecheck phase.  (See typeFlow.ts.)

Hope this helps,

- Joe

Oct 5, 2012 at 8:05 PM


I will have a look more thoroughly at the source files.


Oct 25, 2012 at 5:18 PM

Is the type inference algorithm documented somewhere (tech report, draft paper), and how does it compare to other JS/AS type systems?

For instance, I found the following surprising:

function f() {
	var result;
	result.x = "hi";	// added property
	return result;
} // type () => any:-(

declare var g: () => {x:String};

function g() {
	var result;
	// result.x = "hi"; // missing property
	return result;
} // type () => {x:String} :-(

console.log(f().x,g().x); // no errors :-(

Oct 26, 2012 at 4:48 PM

In your first example, type inference will infer the type of 'result' as any, and it will keep that type.  The reason being is that in general we can't guess types by looking at code (though we could in simple examples like yours).  A slightly more complicated example makes things more difficult:

function f() {
    var result;
    if (random_bool()) {
        result.x = "hi"; // add x property
    else {
        result.y = "bye";  // add y property
    return result;
By keeping the type inference more localized, it's both easier to reason about (and easier to optimize for in the compiler).
A similar situation happens in your second example.  For example:
function g(): {x: string;} {
    var result;
    // result.x = "hi"; // missing property
    return result;
} // type () => {x: string} :-(

The type of 'result' is 'any' because there isn't an initialization on "var result". 

Oct 26, 2012 at 10:27 PM

That is why I was asking for a type system description - not what the code currently does, but what you are aiming for, and how your aims relate to the other JS/AS type systems out there.

Tracking types from object updates is standard in implementation-level "hidden class" inference, and I thought that most JS type system research was trying to merge control flow information into the type analysis, even down to dynamic-type-check guarded conditionals (so far, I've only read a fraction of the papers I've found, but that seemed to be a common thread).

The problem with your random conditional example is that the paths are merged back together, with no unifying information to use after the merge, and little use during the split. That is a worst case.

That is different from straightline update code, which unfortunately is common in JS, since some of the core object APIs (such as object extension) are imperative, rather than functional. So, straightline update code will need to be handled in practice. In pre-ES6 code, one needs to go even further, to handle the various object extension and module export library functions out there - it will take a lot of time before all of that is converted to use modules and classes.

As for the second example: yes, the type for 'result' is 'any', but trying to convert that to the declared '{x:string}' would trigger a warning in most type systems (not in the AS3 one, perhaps). And if you consider that the type of an uninitialized variable is really representing an undefined value, something looks very wrong (the type system allows me to use an undefined value as if it had a property, without so much as a warning).

PS. call me old-fashioned, but a proper mailing list would be nicer for community involvement. Neither the forums/issues, nor their email notifications offer the same functionality/convenience. And TypeScript as a typed ES6 tranpiler is interesting enough that many JS coders and tool hackers might want to be involved;-)