Author here. Thanks for the correction.

You caught me red-handed for not testing these codes in playground.

In JS it's the function would be converted to a string representation of its code and concatenated to the result of `bar(someNumber)`.

Some quick playing with ts-node says that the same thing should happen, depending on the return type of bar. Given the definitions above, it should throw a TypeError, but if bar returned a string, I think it would still behave as I said.

I was unsure if this comment was sarcasm so I tried and concatenating a function and a string in JS actually results in the source of the function being concatenated with the string.

<rant> This whole "wow I thought implicit type coercion in JS was a joke" style comment got old 10 years ago. If you look at where JS came from (the 90s browser) and what it tried to do there then you should be left with few surprises looking it JS code snippets. If you don't understand what a language was designed for and how it evolved how can you be surprised at the results of code snippets? Because it's not the same as every other language? What would the point of the new language be then?</rant>

It’s not that the language is different, it’s that the default is stupid. It’s much more likely that if I’m trying to concatenate a string and a function, I’ve mistyped something, not that I want the source code of the function.

You can always include some additional function which takes a function as an argument and prints the source code as a string for the 4 people in the world who rely on function to string coercion, why is it a default behavior with no visibility?

I get it, JS is different from C or C++ and every other language but we call out poor design decisions by comparing them to expectations fostered by other languages

Again how can you say it's an outrageous default if all you reference is what you think it should have done from a generic language PoV not looking to understand why it does it that way?

Javascript came in as a scripting language for working with the untyped string content of a browser so you get dynamic duck typing where it tries to make the types work (generally towards string since that's what the browser had) instead of having the scripter trying to make some simple web content dynamic do more type checks than actual code. In JS functions are just objects (like most everything) and objects. Combine the above so when you say object + "foo" it coerces object to string and it shouldn't seem outrageous just not what you're used to.

Now a fair question would be "Why doesn't TS consider this an error out of the box".

Also for those annoyed by this in places JS wasn't originally designed to go (heavy app logic, server backends, desktop applications) you might want to look at the no-implicit-coercion rule in ESLint or similar.

I have been coding TypeScript for the last 2 years, non-stop, which also shielded me from the surprise of the function's body getting stringified.

It's relatable. Most developers did not grow up with the knowledge of JS language's Design principles, which is not something I would criticize anyone for.

Plus the undefined name 'number' in foo(). TypeScript flags that along with 'baz();'.

What does puzzle me is that TS doesn't flag 'return bar(someNumber) + bar;' - I'm curious if anyone knows why it seems to allow that.

I think because the return type hasn't been specified for the function, so it is inferring the return type from the return statement (which means it is "correct").

Don't forget JavaScript (and therefore typescript) will let you concatenate a lot of random types together without error.

Sounds like you posted this comment after only reading that example at the beginning. Did you read the rest of the article? What were your thoughts at the end of it?

Correct. There's about 19 billion opinionated articles on the internet. If I start one off and it seems immediately wrong, I'm not going to take the time to read the entire essay. You have to have some kind of filtering heuristic for content.

You'll take the time to leave a comment, though. And engage in follow-up discussion, apparently.

It's not a long read and it has some useful content (that I mostly agree with) despite having a bunch of minor mistakes. I noticed them too, but instead of loudly dismissing the entire thing on a public forum my first instinct was to look for a repo so I could send a pull request (sadly I didn't find one).