You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a is NaN, b is the string "test1NaN". This is valid - unary minus and unary plus (your second line is a binary plus with a unary plus in the right hand side) operators coerce strings to numbers. (And binary + with a string as the first argument coerces numbers to strings!) For example, +"23" will be the number 23.
So yeah, that this is allowed is expected - and also somewhat common, it's actually (usefully) used in one place within the TS compiler (inside the parser). It's somewhat more reliable than doing Number("023") and definitely more reliable than parseInt("023").
As far as types are concerned, it all checks out - however, if you're looking to forbid this kind of usage of unary plus/minus in your own code, I can recommend writing a tslint rule for it.
Activity
weswigham commentedon Feb 11, 2016
a
isNaN
,b
is the string"test1NaN"
. This is valid - unary minus and unary plus (your second line is a binary plus with a unary plus in the right hand side) operators coerce strings to numbers. (And binary + with a string as the first argument coerces numbers to strings!) For example,+"23"
will be the number23
.So yeah, that this is allowed is expected - and also somewhat common, it's actually (usefully) used in one place within the TS compiler (inside the parser). It's somewhat more reliable than doing
Number("023")
and definitely more reliable thanparseInt("023")
.As far as types are concerned, it all checks out - however, if you're looking to forbid this kind of usage of unary plus/minus in your own code, I can recommend writing a tslint rule for it.
tomijah commentedon Feb 12, 2016
Ty.