Type guard handling with boolean compares

[HolgerJeromin]

TypeScript Version: 1.8.0

Code

let myAny: Array<string> | string;
myAny = 'anythinghere';

if (Array.isArray(myAny)) {
    let narrowed = myAny;
}

if (!!Array.isArray(myAny)) {
    let narrowed = myAny;
}

if (Array.isArray(myAny) === true) {
    let notNarrowed = myAny;
}

Expected behavior:
All three should result in the same type guard.
Tested with Visual Studio 2015 Update 2 and TypeScript Playground mouse hover.

[kitsonk]

There are limits that the compiler goes to when trying to statically analyse the code. JavaScript has lots of patterns that are perfectly valid at run-time, but aren't necessarily worth coding for in the compiler for...

For example all of these are "valid" statements:

Array.isArray(myAny) === !!'0';
Array.isArray(myAny) != undefined;
Array.isArray(myAny) === Boolean(1);
Array.isArray(myAny) == 1;
Boolean(Array.isArray(myAny)) !== false;
Array.isArray(myAny) > false;

[HolgerJeromin]

Yes, there are always esoteric difficult usecases, but my usecase was
if (Array.isArray(myAny) === false)or if (Array.isArray(myAny) !== true)

I had to change the code to the less readable
if (!Array.isArray(myAny))

[yortus]

The more powerful type guards become, the more expectactions there are that they should work for all cases that can be statically reasoned. I think there were less issues raised back when they were rudimentary and people's expectations were much lower!

One possible solution would be if TypeScript eventually got compile-time expression evaluation/simplification facilities as exist in some other languages/compilers (eg C++, D). Then any ridiculous expression, like Array.isArray(myAny) === !!['truthy'][0], would still work as a type guard, as long as it could be statically evaluated/simplified, and it wouldn't need a special case in the compiler.

[RyanCavanaugh]

!! is strictly out. There's no reason to write that in an if and we'll continue to interpret that as a "stop looking at my type guard" workaround.

=== true / === false seem OK to support, though in general I'd advise being very careful writing code like this in JS as often people will actually return truthiness/falsiness instead of true / false from is* functions.

[RyanCavanaugh]

This doesn't seem common enough to support. In most cases === true is a code smell and doesn't appear often enough to justify the extra complexity to support it.