User-defined type guards don't work for all types

[sophiajt]

If the user defines a type guard for a boolean, as in this example:

function isBool(a: any): a is boolean {
    return (typeof a === "boolean");
}

function bob() {
    var z;

    if (isBool(z)) {
        z; // type of z is still 'any'
    }
}

...then z is not properly refined to 'boolean'. It stays 'any'. I think the expected behavior here is for the type guard to refine to boolean inside of the if check.

[tinganho]

I did this intentionally to mimic the instanceof check in:
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L6285-L6287

let z;
class A {}
if(z instanceof A) {
    z; // any
}

Should I remove it @JsonFreeman ?

[JsonFreeman]

We've gone back and forth on the narrowing of any. I think the philosophy here (like instanceof) is that narrowing should give the user access to more properties than if narrowing had not occurred. In the case where the type being narrowed is any, narrowing actually gives you access to fewer properties. So that is the reason for not narrowing.

I think it's fine in principle to change the rule for both type predicates and instanceof, but it depends on the impact to actual code. I do think that any is a weird beast because unlike other types, everything is allowed, but nothing is encouraged. So I think having a different rule for any with respect to narrowing does make sense.

In other words, I think it makes the most sense as it is, but a case could be made for changing it.

[sophiajt]

I think we can't necessarily treat it as instanceof. For example:

function bob() {
    var z;

    if (typeof z === "boolean") {
        z; // type of z is 'boolean'
    }
}

But abstracting into a user-defined type guard in a well-typed way actually changes what we know:

function bob() {
    var z;

    if (isBool(z)) {
        z; // type of z is still 'any'
    }
}

I think the reasonable assumption here is that abstraction would not lose the capability to refine the type, and that a user-defined type guard could be used instead.

Not to say that you'll be making up your own booleans... but I guess I'm arguing for a solution that's general.

[JsonFreeman]

@jonathandturner I see your point. The question is, when we see a type predicate of the form x is T, how do we know if it corresponds to a typeof style type guard versus an instanceof style type guard? Sounds like you want to narrow for the typeof case, but not the instanceof case?

One idea is that if T is a primitive, we assume it's a typeof style type guard. If T is anything else, it's instanceof. Not sure if that's a good rule, but it's an idea.

[mhegazy]

The behavior here matches the intended design. it does not match the user intuition though. we need to consider this for both instance of and user defined type guards.

[JsonFreeman]

Whether or not we decide to narrow, I do think it makes sense to keep the behavior consistent between the type predicate form and the instanceof form.

[sophiajt]

We talked about this at the design meeting and agreed this is a bug.

[JsonFreeman]

Is it also a bug for instanceof?

[sophiajt]

Doesn't this already work for instanceof? I was thinking the problem was that the ideas worked for instanceof-style checks but not typeof.

[mhegazy]

@JsonFreeman we will need to change both user defined type guard functions and instance of.

[JsonFreeman]

Right, so to summarize, the intended behavior for type predicates and instanceof, is that they should narrow when the initial type is any, which will be a breaking change.

[mhegazy]

correct. adding the breaking change label.

[dsherret]

👍 for narrowing any. Good decision.

[mhegazy]

We have a discussion about this and narrowing any a. is a breaking change, b. is not clear that there is any value added, and more importantly, c. there is no way to opt-out unless cast is used inside the blocks.

with union types available now, the user specified any explicitly (assuming noImplicitAny is on) and i would take that as an indication that she does not want more compiler checks. reverting this again because of a type guard seems more annoying than helpful.