Unable to use !== on union types with a string literal types

[e98cuenc]

TypeScript Version: 2.0.3

Code

class Color {
    constructor(public r: number, public g: number, public b: number) {
    }
}

var f: 'none' | Color = new Color(0, 0, 0);
f !== 'none';

Expected behavior:
No errors

Actual behavior:
error TS2365: Operator '!==' cannot be applied to types 'Color' and 'string'.

If the tested variable is a member of an object, the above code works:

class Color {
    constructor(public r: number, public g: number, public b: number) {}
}

var f: { x: 'none' | Color } = { x: new Color(0, 0, 0) }; 
f.x !== 'none';

[ahejlsberg]

This is working as intended. The error in the first example is reported because the control flow analyzer knows that the actual type of f in that location is Color (due to the assignment right above) and a Color value is not comparable to a string value (effectively the comparison doesn't make sense). Contrast that with this example

function foo(f: 'none' | Color) {
    f !== 'none';  // Ok
}

Here the comparison is ok because the control flow analyzer only knows the declared type for f, so f might be the string literal 'none'. The same is true in your second example (although it is arguable we could know that f.x is a Color, we only track direct assignments to f.x).

If you really want a 'none' value that you can always compare to a 'none' | Color, you can explicitly give it that type in a type annotation:

const None: 'none' | Color = 'none';

Alternatively, you can use the expression 'none' as ('none' | Color).

[normalser]

@ahejlsberg Isn't it the wrong assumption of control flow analyzer about actual type of f in that location ?

Consider:

class Color {
    constructor(public r: number, public g: number, public b: number) {
    }
}

var f: 'none' | Color = new Color(0, 0, 0);
function test() {
    f = 'none'
}
test()
f !== 'none'; 

[ahejlsberg]

@wallverb Effects of assignments in nested functions is an orthogonal issue. We currently don't account for them, and given the first class nature of functions we'll never be able to completely analyze such side effects without being overly conservative. There have been many discussions on this topic and #9998 summarizes where we are.

[normalser]

Thank you @ahejlsberg . Great discussion

[aluanhaddad]

This feature is catching common logic errors and forcing people to write cleaner code that has fewer redundant conditionals. It's absolutely fantastic.
Found a bug today that was due to writing || instead of &&. I have a feeling a lot of languages are going to start adopting these kinds of features over the next few years ❤️