TypeScript Version: 2.0.2.0
Code I know the code is a bit stupid, but I actually have these kind of tests in my code (m
As Erlang developer I used to see this kind of errors in Erlang, but was unsure what it means in TypeScript, here's example that will help you understand the problem:
let answer: "yes" | "no" | "maybe" = "yes";
if (Math.random() > 0.5) {
answer = "maybe";
}
if (answer === "yes") {
console.log('yes');
}
if (answer === "no") {
console.log('no');
}
It will not compile with error:
error TS2365: Operator '===' cannot be applied to types '"yes" | "maybe"' and '"no"'.
First, here's the solution
let answer = "yes" as "yes" | "no" | "maybe";
Now the explanation:
Since this code is very simple and could be understood at compile time, TypeScript knows that there's no where in code where answer
could become "no"
, so it just says to you (although in quite cryptic form) that answer is always not "no", so there's literally no reason to ever check if it is. But (as in Erlang) this can happen for quite obvious reason, when you for example decided to comment out some code for debug that was making answer
to become "no"
. Now if we use let answer = "yes" as "yes" | "no" | "maybe";
or let answer = <("yes" | "no" | "maybe")>"yes";
it will make TypeScript think that "yes" can be "no" even if you can't see it in code. So for case of temporarily removed code there's second solution:
if (0) {
answer = "no";
}
Even though this condition will never be true it is "complex" enough for TypeScript compiler to think that it can be true. My Erlang approach is to use when X and not X
which would be if (x && !x) {
but at least in 2.4 you can just use number expressions.
But at some point compiler might just be right and then solution is to remove check for "no"
:)
So returning that back to the OP's question, to make your code compile you need to change it to:
var a = false;
var b = false;
If compiler knows that, you probably knew that too.
Literal types have many advantages, as it lets the compiler make types as narrow as possible. Your use case is one that comes up very rarely, but wanting types to be as narrow as possible permeates the entire design of the language. So yes, while it makes your life harder in this one specific case, it makes sense in the language as a whole. Users would have to suffer a significantly worse language, just to support this one rare use case.
Unfortunately, you will have to use the explicit typing you suggest yourself in the second example. I don't see this ever being fixed, because the majority of users wants the language to yell if they try to do this. It's probably the sign of a bug in a large majority of cases.
Faced the same issue in a scenario as the following:
let a: string;
a === 'some-value1' && a === 'some-value2'; // <==
The second line produces the same error and maybe because Typescript is smart enough to know that a string type at a given moment cannot contain two (or more) different string literals.
The correct approach for the above expression would be to use OR in the expression:
a === 'some-value1' || a === 'some-value2'; // works fine :)
why aren't 5 and 2 considered as type 'number'
The have the literal type 5
and 2
. e.g.
var x: 5;
// can only ever be assigned to 5
x = 5; // okay
x = 2; // Error
I don't see an actual use case for wanting it not to be an error. This is just the compiler trying to help you. Feel free to create an issue if you see sufficient motivation