4 ms·
Not trying to defend the craziness, but, when you are trying to do []+{} and "foo"-1, you can kinda expect unexpected results if you know that JS does type coer
by karterk 15y ago
Not trying to defend the craziness, but, when you are trying to do []+{} and "foo"-1, you can kinda expect unexpected results if you know that JS does type coercion.
- jlouis 15y agoThat is not the problem here. The problem is that this might by the code piece "x + y" where x and y is in your scope and happens to be [] and {}. The resulting value is then highly confusing to a programmer. A language that enforces explicit type conversion (some call these strongly typed languages) would not allow this, but require you to write something like "string(x) + string(y)" if you really wanted such behaviour. I think it is rather bad semantics actually.
- ricardobeat 15y agoI can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects. That would be highly confusing. You always have the option to use Number(x) + Number(y) (+x) + (+y) String(x) + String(y)
- jerf 15y ago"I can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects." That's precisely the problem. You don't expect them, but there's nothing to prevent it from happening, so it does. Your proposed solutions don't solve the problem, they occur too late. By the time you're adding together two non-numbers (and non-strings) you've already lost, trying desperately to cast them to numbers first is also wrong, along with so verbose that nobody will ever do it.
- ricardobeat 15y agoYeah, that was stupid. What I mean though is I can't imagine code that gives chance for this to happen. Putting an array where a number should be is a very visible mistake.