Issue 1:
I just found out that property access expressions doesn't work on type predicate functions and instanceof type guards.

class A {
propA: number;
}

class B {
propB: number;
}
class C {
propC: A;
}

declare function isA(p1: any): p1 is D;

interface D {
a: A | B
b: A | C;
}

let d: D;
if (isA(d.b)) {
d.b.propA; //error
}

function foo(d: D) {
if (d.b instanceof A) {
d.b.propA // error
}
}

I'm not sure if there is an easy fix on this problem. We are provided just a symbol when narrowing. That symbol represent the left most expression and then we walk up the if statement. There is no easy way of controlling symbol by symbol on each namespace in a property access expression in the if-statement-body. Because there is no info about the property access expression provided in getTypeOfSymbolAtLocation(symbol: Symbol, node: Node).

I also found that type assertion expressions are also not working in type predicate functions. But I will land a fix on that.

if (isA(<A>union)) {
a = union;
}
if (isA(union as A)) {
a = union;
}

Issue 2:
This is a proposal for using property access as another form of type guards (see #900) to narrow union types. While we're investigating expanding the power of type guards (#1007) this feature would support the natural style that JavaScript programmers have in their code today.

Using property access to narrow union types

var x: string|number;
if (x.length) { // no error even though number lacks a length property
var r = x.charAt(3); // x is of type string inside this block
}

var r2 = x.length || x * x; // no error, x narrowed to number on right hand side, r3 is number

var y: string[]|number[]|string;
if (y.length && y.push) {
// y is string[]|number[] now
var first = y[0]; // first is string|number
if (first.length) {
// first is string in here
} else {
// first is number in here
}
}

We do not expand the situations in which types are narrowed, but we do expand the known type guard patterns to include basic property access. In these narrowing contexts it would be an error to access a property that does not exist in at least one of the constituent types of a union type (as it is today). However, it would now be valid to access a property that exists in at least one, but not all, constituent types. Any such property access will then narrow the type of the operand to only those constituent types in the union which do contain the accessed property. In any other context property access is unchanged.

Invalid property access

var x: string|number;

var r = x.length; // error, not a type guard, normal property access rules apply

if (x.len) { } // error, len does not exist on type string|number

var r3 = !x.len && x.length; // error, len does not exist on type string|number

var r4 = x.length && x.len; // error, len does not exist on type string

Issues/Questions

Should the language service behave differently in these type guard contexts? Should dotting off a union type in a type guard list all members on all types rather than only those that exist on all of them?

Need to understand performance implications

I have a sample implementation and tests in a branch here: https://github.com/Microsoft/TypeScript/tree/typeGuardsViaPropertyAccess. There're a couple bugs remaining but examples like the above all work and no existing behavior was changed.