Differing user-defined type guard and 'typeof' type guard behaviour when narrowing 'any'

[pimterry]

In the below code, using a typeof type guard and an equivalent (I thought) user-defined guard, only one error is produced.

var y: any;

// Built-in type guard
if (typeof y === "string") {
    y.hello = true; // Correct error - 'hello' does not exist on type string
}

// Equivalent user-defined type guard
function f(x: any): x is string {
    return typeof x === "string";
}

if (f(y)) {
    y.hello = true; // No error with user-defined guard
}

Playground demo. Looks like user-defined type guards won't narrow from any, in any circumstances, as far as I can tell.

[pimterry]

Any thoughts on this?

Looks clearly incorrect to me, but I can't find a definitive spec on user-defined type guards, which makes it difficult to verify. I'd be very surprised that they're actually intended to differ from built-in type guards in this regard though.

[DanielRosenwasser]

The thing is that user-defined type guards are "weaker" than typeof guards given that an implementation might use instanceof in some way. instanceof type guards have to be weaker because narrowing a value's type from any to Object limits what you can do with it. Clearly this gives you a not-so-great experience when you try to work with primitives.

@ahejlsberg and I have discussed this offline and one idea we have is that for any primitive type covered by a typeof type guard (i.e. string, number, boolean, and symbol), we should consider performing the same narrowing as a typeof type guard because that's usually how you were going to implement something like isString.

[DanielRosenwasser]

If anyone is considering sending a PR for this, give a heads up here so we don't duplicate work. 😃

[thebanjomatic]

I've been playing around with the controlFlowTypes branch and it appears as if the same narrowing behavior should probably apply there as well:

For example:

let a: any;
a = "10";
a; // a: any ... expected a: string
a.toFixed(2); // no compile error!

I have been using noImplicitAny in my own code base, but I can imagine some smarter behavior here could only help to find bugs in code which does wind up using any (whether implicitly or explicitly).