Types error

[webstyle]

TypeScript Version: 1.8.10

Code

let myString: string = '123';

myString += 123123;

console.log(myString); // returns number

*Expected behavior: Type 'number' is not assignable to type 'string'. *

*Actual behavior: 123123123 (number, no error) *

[shelby3]

In JavaScript, the + operator serves as both the string concatenation operator and the addition operator. It coerces a number to a String (or vice versa depending on precedence, which is the famous design mistake of JavaScript).

I presume TypeScript honored this idiomatic JavaScript flaw, since its purist design goals are to not introduce new expression-level syntax, i.e. if you want this fixed you need to petition the ECMAScript standard.

See Ma, I am learning fast.

[webstyle]

But TypeScript had to correct this design mistake.

[kitsonk]

@webstyle it is following the runtime coercion of JavaScript. It actually returns a string, not a number:

let myString: string = '123';

myString += 123123;

console.log(typeof myString); // logs: string (not number)

This is more the domain of a linter, as the type system in this case is sound. Number 123123 is being implicitly coerced at runtime. Others may actually depend upon this implicit coercion although the intent is pretty poor and confusing. What is one person's design mistake is another person's feature.

[shelby3]

In this case, I would argue it might be better to break the purist design goals of TypeScript, and introduce a new expression-level syntax for a string concatenation operator (e.g. # or ++) which is erased to + in the emitted output, but which only coerces to String (never from String to Number) or which never coerces. So then the programmer would have the option to use this new operator to get more clear compilation results and expression of intent. They would also have the option to continue to use + for string concatenation to retain the JavaScript semantics.

I realize my preference might not be shared with some (or even most) of the community and I would accept if they want to downvote this comment to indicate their disagreement with my preference. The downside of introducing new non-standard expression-level syntax is that it can become a pain point and incongruity with the rest of the ECMAScript universe; and with a myriad of transpiler syntax(es) then the ECMAScript ecosystem becomes ever more disjoint. However, TypeScript is introducing new syntax, so it is impossible to not have disjointedness form during competitive, free market experiments to improve a standard. I suppose the argument is to limit new syntax to outside of expression-level (and in TypeScript's case intended only for new syntax pertaining to erased typing) so at least expression-level remains consistent in the ECMAScript ecosystem. But in this case especially I would argue that since ECMAScript only has dynamic typing, they aren't likely to make it a priority to add a dedicated concatenation operator, so it seems to fall more into the responsibility of TypeScript. However I would also remain sympathetic to those who don't want to move too fast towards the best possible typing, and would instead prefer to retain ECMAScripts flaws for the sake of consistency in the ecosystem. I come at this from the perspective of hoping to influence standards by mass adoption in the free market, so I tend to avoid design-by-consensus to some extent although I try to consider this pragmatically. Microsoft (and Adobe) has (have) definitely learned the hard way (Silverlight, Flash, ActiveX in browser, IE proprietary APIs, etc) that proprietary syntax most often loses in the market place. I certainly don't consider design-by-isolation to be valid.

@kitsonk wrote:

This is more the domain of a linter, as the type system in this case is sound.

A linter isn't carried around with my code where ever it goes. It is not a fix to the design of the type system. That could be considered an advantage or disadvantage, depending on your perspective of the above.

[RyanCavanaugh]

The intent here is that string concatenation with other types is super common and idiomatic, e.g.

let message = 'Error code ' + response.code + ' was returned from the server'.

Forcing you to call toString here is really cumbersome, and is doubly annoying in debug messages where it may not be safe to do so:

// No problem if I wrote "got undefined from server" to console
console.log('DBG: Got '+ x + ' from server');

str += num is certainly slightly more suspicious than the above examples, but for consistency's sake we generally want x = x + y to be identical in behavior to x += y