Reputation: 723
The expression 1==2
causes TypeScript to give the error Operator '==' cannot be applied to types '1' and '2'
. What are the reasons for TypeScript treating these values as being of a different type (the typeof
operator, rather predictably, says that they're both number
s)? Is it a design decision to specifically apply this to numbers, or a byproduct of the overall typing system? What harm could be caused by allowing comparison of literals?
Upvotes: 9
Views: 327
Reputation: 19742
1
and 2
in this context are considered so called literal numbers. It means that value 1
has type 1
and thus can only be 1
, same with 2
. Given that, the expression of 1==2
doesn't make sense because 1
can never be 2
, or more precisely their types mismatch, you can't compare apples to oranges.
Here are the rationale and in depth details on where literals types are assumed by default:
About literal types:
One of many examples as to why literal types are useful:
Upvotes: 7
Reputation: 151441
When TypeScript peforms type inference on the expression 1
, it gives it the type 1
, not the type number
. You can see this if you examine code like this:
const a = 1;
If you use your IDE to query the inferred type of a
, you'll see that the type of a is 1
. In the TypeScript playground, for instance, you get a tooltip that says const a: 1
.
So in if (1 == 2)
, 1
has type 1
and 2
has type 2
. TypeScript does not allow you to compare them because they are of different inferred types. This is part of the type safety TypeScript gives you.
You can work around it with:
if (1 as number == 2) {
}
And you mentioned in a comment that you were doing the 1 == 2
comparison because you could not do if (false) { ... }
due to the compiler complaining about unreachable code. I can work around that problem with this:
if (false as boolean) {
console.log("something");
}
Upvotes: 5
Reputation: 250056
Typescript can create a type from any constant value. This when combined with union types creates a very powerful way of expressing what a function takes as an argument for example:
function doStuff(p : "yes"| 1| true| "no"| 0| false ){
}
doStuff("maybe"); //Error
doStuff(3); // Error
doStuff(1) ; //OK
You are experiencing the unfortunate side effect that errors such as yours instead of being reports as expression is always false
turn into type compatibility errors instead.
Upvotes: 4