GeezerVison

Latest commit adds support for type guards along the lines of "Local Meaning of Union Types" in #805. Some examples of what is now supported:

function foo(x: number|string) {
    if (typeof x === "string") {
        return x.length;  // x has type string here
    }
    else {
        return x + 1;  // x has type number here
    }
}

function isLongString(obj: any) {
    return typeof obj === "string" && obj.length > 100;  // obj has type string after guard
}

function processData(data: string|() => string) {
    var d = typeof data !== "string" ? data() : data;  // d has type string
    // Process string in d
}

class NamedItem {
    name: string;
}

function getName(obj: any) {
    return obj instanceof NamedItem ? obj.name : "unknown";
}

The type of the local variable or parameter may be _narrowed_ in the following situations:

• In an if statement with a condition that contains a type guard.
• In a conditional statement with a condition that contains a type guard.
• In the right operand of an && operation where the left operand contains a type guard.
• In the right operand of an || operation where the left operand contains a type guard.

A _type guard_ is one of the following:

• An expression of the form typeof x === "..." or typeof x !== "..." where x is the identifier of a variable or parameter and "..." is a string literal. When the string literal is "string", "number", or "boolean", the type guard either changes the type of x to that primitive type or removes that primitive type from the possible types of x (when x is of a union type). When the string literal is something other than a primitive type name, the type guard removes all primtive types from the possible types of x in cases where the guard is known to be true.
• An expression of the form x instanceof C where x is the identifier of a variable or parameter and C is a constructor function. When the type guard is known to be true, the type of x is changed to the type of C.prototype.
• An expression of the form !x where x is a type guard.
• An expression of the form x && y where one or both of x and y are type guards.
• An expression of the form x || y where one or both of x and y are type guards.

A type guard for a variable x has no effect if the statements or expressions it guards contain assignments to x. For example:

function foo(x: string|number) {
    if (typeof x === "string") {
        x = x.length;  // Fails, x still of type string|number here
    }
    var n = typeof x === "string" ? x.length : x;  // Ok, n has type string
}

Note that type guards affect types of simple variables and parameters only (e.g. x). They have no effect on the types of property accesses or other expressions (such as x.y and x()). The latter would require complicated aliasing analysis.

Also note that it is possible to defeat a type guard by calling a function that changes the type of the guarded variable. It would quite difficult to exhaustively prove that a variable isn't modified by function calls.

The type guard concept looks fantastic. I really like it.

So are

"string" === typeof obj

and

"string" !== typeof obj

not type guards?

Daniel Rosenwasser (@DanielRosenwasser) Regarding "string" === typeof obj, no I don't think those would be type guards. Nor would all the various forms that can be constructed by adding parentheses. I think there is something to be said for keeping the pattern simple and consistent.

Latest commit improves type argument inference for union types.

When inferring to a union type, we first infer to those types in the union that aren't naked type parameters. If that produces no new inferences, and if the union type contains a single naked type parameter, we then infer to that type parameter.

To infer from a union type we infer from each of the types in the union.

With these changes the following now works with zero type annotations in the actual code:

declare class Promise<T> {
    static resolve<T>(value: Promise<T>|T): Promise<T>;
    then<U>(onfulfilled?: (value: T) => Promise<U>|U): Promise<U>;
}

var p1 = Promise.resolve("hello");  // p1: Promise<string>
var p2 = Promise.resolve(p1);       // p2: Promise<string>
var p3 = p1.then(i => {             // p3: Promise<number>
    if (true) {
        return Promise.resolve(10);
    }
    else {
        return i.length;
    }
});

Latest commit fixes issue where overly eager subtype reduction in union types would cause a union type to become any because of a circular reference.

Also, the compiler now simply uses union types for the results of the ?: and || operators instead of the more complicated best common type scheme we had before.

Did generate a declaration file for large UI library (Qooxdoo) that had its own OO framework. And of the 3 main things missing to really be able to have a very accurate declaration file (and also use that library to its full potential), you guys already addressed 2 of them in recent weeks. Great job!!

Things that were missing from TypeScript version 1.0 :

• Protected keyword (done)
• Union type (almost done I guess)
• Mixin (can always hope for ;)

Latest commit corrects contextual typing with union types.

• When an object literal is contextually typed by a union type U, the contextual type for a property P in the object literal is a union of the types of the P properties from those types in U that has one.
• When an array literal is contextually typed by a union type U, the contextual type of an element expression is a union of the numeric index signature types from those types in U that has one.
• When a function expression is contextually typed by a union type U, a contextual call signature is available only if each type in U that provides a contextual call signature provides the same one.

Some examples:

var f: number | (x: string) => number;
f = 5;
f = x => x.length;  // x is of type string

var a: Array<number | (x: string) => number>;
a = [5, x => x.length];  // x is of type string

interface A {
    p: Array<number>;
}

interface B {
    p: Array<(x: string) => number>;
}

var obj: A | B = {
    p: [x => x.length];  // x is of type string
};

This commit also changes array and object literals to never produce a result of the contextual type, but rather to use union types to express the exact shape seen. Without this change the last example above wouldn't work.

I've translated into French the spec preview #805: http://www.developpez.net/forums/d1476332/webmasters-developpement-web/javascript-ajax-typescript-dart/typescript/typescript-unions-types-cours-d-implementation/#post8002985