This condition will always return 'false' since the types have no overlap. Again.

[Busyrev]

TypeScript Version: 3.1.0-dev.20180717
Error: This condition will always return 'false' since the types '"work1"' and '"work2"' have no overlap.
Error: Type '"work2"' is not comparable to type '"work1"'.
TypeScript Version: 2.9.2
Error: Operator '==' cannot be applied to types '"work1"' and '"work2"'.
Error: Type '"work2"' is not comparable to type '"work1"'.

Search Terms:
Operator '==' cannot be applied to types
This condition will always return 'false' since the types have no overlap.
Type is not comparable to type.
Code

function doWorkIf(work: 'work1' | 'work2'): void { 
    work = 'work1'; // made this for debug purpose and TS alerts error
    if (work == 'work1') {
        // do something
    }
    if (work == 'work2') { // YEA typescript, I know what I do, why you alert me??
        
        // do something
    }
}

function doWorkCase(work: 'work1' | 'work2'): void { 
    work = 'work1'; // made this for debug purpose and TS alerts error
    switch (work) { 
        case 'work1':
                // do something
            break;
        case 'work2':
                // do something
            break;
    }
}

Expected behavior:
no error
Actual behavior:
error
Playground Link: link

Related Issues: #25642

Sorry, but it's me again. Why I have to write ugly code removing typing info (work = 'work1' as any; fixes the issue) to make my correct code work? I already specified allowUnreachableCode option to true. Why TS alerts me? This kind of alerts should be an linting rules, or may be configurable feature. I read #25642 (comment). I think all we shoult think about alerting correct code. It's really bad idea. Yea, I have to throw this error detection away in my own fork, but I am not always use the fork, its made for special puprose. I love typescript, and using it from 1.3 but this feature is really makes me angry.

Now constructive proposals:

• Create additional compiler option, like allowUnreachableCode to disable it.
• Move this error to ESLint or TSLint.
• Disable this error detection while allowUnreachableCode is set to true.
• Totally throw away this featue.
• Improve it with nominal types detection, and make this error detection safe for correct code.

Any kind of solution will be much better than now. May be there is another ways to solve it... Sorry, I'm really angry. Typescript is the best thing that happens in web, and I want to make it better.

[ghost]

You could write if ((true)) work = 'work1'; which is generally useful for removing control-flow information.

[Busyrev]

Yea, there is many ways to fool compiler. And I have no claims to flow analysys. This is only issue about comparing things that TypeScript thinks uncomparable.

[mhegazy]

There are limitations of control flow analysis that we are aware of. more about these in #9998. The current design and implementation tries to balance value added vs. false positives. I do not think there is a solution that catches all bugs, and not flag valid use cases. User intent is hard to figure out in many of these cases.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[alvarosanmartinh]

Sorry for commenting when it is closed but maybe i could help someone.

In my case the error was triggered by:

*ngIf="fooArray.length === 0"

so i modified it to be:

*ngIf="fooArray.length < 1"

Makes no sense to me, but it works.