exploring javascript type auto-coercion (and its pitfalls)

gistfile1.txt

// **********
// NOTE: this is a stupid trivial example illustrating automatic
// type-coercion, not an example of the kind of data-structure logic
// you'd ever actually use. don't miss the forest for the trees.
// Read down in the comment thread for 'myCoolString' for a slightly
// more sensible example.
//
// NOTE #2: this gist thread was spawned from a twitter discussion
// about `parseInt(0/1,19)==18`:
// https://twitter.com/getify/status/221009838006747136
// **********


var myObj = {
   _val: [10,5,7,9,-1,4,13,6],
   toString: function(){
     return ""+Math.max.apply(this,this._val);
   }
};

parseInt(myObj); // 13 ==> this is part of what makes javascript awesome

Javascript is awesome because you can bastardize toString (which is supposed to return a stringified representation of the object) so that you can bastardize parseInt (which is supposed to parse a string into an int) to turn it into a max function? Wouldn't myObj.maxVal == 13 make more sense?

@bhudgeons missing the forest for the trees, my friend.

I am trying to illustrate that complex objects can serialize themselves to a useful string representation (like Infinity does with "Infinity"), and that where a string is expected, this coercion is automatically performed, which is sometimes quite helpful.

There are some cases where it bites you, but responsible developers can, I think, successfully navigate those, so they can get the power that these behaviors give us.

@getify can you (if you want to, say when designing a javascript library) restrict coercion when the result of coercion might be particularly error prone, or lead to results that would be clearly wrong?

@bhudgeons yes, using a run-time checker like this: http://restrictmode.org/ i would recommend using it just like a linter, to make sure error-prone coercions are avoided.

@getify ... sorry ... I wasn't clear. If I was designing a library, could I make it so that certain functions would not allow coercion (even if my library users weren't using restrictmode or something similar)?

you cannot "force" coercion by any means except your use of operators on a variable. so, to answer your question, you can avoid coercion of what people pass into your library by not using operations that will coerce it unsafely.

for instance, if you accept a string param, you can either:

1. start using it as a string, in which case automatic coercion will occur; OR
2. "type check" the input (with typeof), and reject the input if it's not the expected type.

ex:

function str_concat(str1,str2) {
   if (typeof str1 != "string" || typeof str2 != "string") {
      throw new Error("String parameters expected.");
   }
   return str1 + str2;
}

That function avoids having numbers, booleans, objects, arrays, etc from being coerced into strings. There wouldn't ever be a "undefined" or "Infinity" stray string show up there from such coercion.

Okay ... so, given that, wouldn't it make sense to have parseInt(Infinity,19) be NaN? Or Infinity? Why can you parseFloat(Infinity)==Infinity? [I'm sure there's some odd "spirit of javascript" justification for that inconsistency.] The point of a function (especially one as seemingly straightforward as parseInt) is to give a well-defined, predictable response, not to empower those with knowledge of a language's esoteric oddities to exploit its insanity to write unclear code like this gist.

Here's where I think we're disagreeing: I'm not complaining about type coercion, and I know that you wrote the code above as an example of what type coercion could do, and not as an example of something you'd ever write outside of a gist. I know what you meant when you said, "forest for the trees". Type coercion can be powerful and useful -- I'm a big fan of it when thoughtfully applied -- but having the capability inside JavaScript doesn't let the implementers of parseInt off the hook for the travesty of parseInt(1/0,19)==18.

Making parseInt behave non-idiotically would not rob you of your "power" to write code that takes advantage of type coercion in a sane way. By making fun of parseInt(1/0,19)==18, I mean to point out, first of all, that that statement is funny. This is mathematically so. It is just wrong. If I had written that function, I would smack myself in the forehead and fix the bug.

If you want to dig for JavaScript hatred (and I must admit I harbor some), it isn't directed at type coercion. It is directed at the litany of funny results you get from a language with many, many odd implementation fuckups like that one.

I'm on record in other forums arguing for giving programmers all the rope they need to hang themselves. I'm absolutely against crippling a language in the name of "programmer safety." That doesn't mean that language implementers can write code that is wrong, and then argue that smart programmers should just avoid using their shitty functions in problematic ways.

@bhudgeons
I don't think anyone would argue JavaScript is perfect. There are plenty of warts and footguns. Brendan Eich is on record many times as saying he wish'd he'd had more than 10 days to implement JavaScript, as many "mistakes" of the language would have been avoided.

So, I'm not arguing that the particular example you mention (parseInt(1/0,19)==18) is "awesome". It's clearly a "WTF" moment at first glance. But I think the real problem is a developer who was unsafely using type-coercion, not that type-coercion gave unexpected results.

The underlying principles are awesome, and the implications of saying that it is "wrong" and should be "fixed" would imply that we erode/erase some of the awesomeness of the underlying powerful behaviors.

Let's dig more into the parseInt(1/0,19)==18 so I can explain what I mean:

---

Should parseInt(x,y) coerce its arguments? You seem to indicate you don't think so, at least for the first param, which is obviously expected to be a string.

If parseInt() didn't coerce its first param, then you would get the following:

var s = String("123");
///...
parseInt(s,10); // throws an error if the param isn't coercible to a primitive `string`

Now, there's two ways we could resolve this. (a) We could say parseInt(x,y) coerces x only if x is a String object, but not if it's anything else. Or (b) we could shift the onus to the developer, and say that they should always do their own value coercion (explicit casting) before calling an interface that is very narrow in what it expects.

(a) Why only the blessed String can be coerced, and not other very-String-like objects? For example, should this not be possible in JavaScript?

var myCoolString = {
   _parts: [
     { val: "12", enabled:true },
     { val: "3", enabled:false },
     { val: "45", enabled: true }
   ],
   toString: function() {
      var ret = "";
      for (var i in this._parts) {
         if (this._parts[i].enabled) ret += this._parts[i].val;
      }
      return ret;
   }
};

parseInt(myCoolString,10); // "1245" => 1245

Again, I know that's still a bit contrived, but please look beyond "the trees" and see that representing fundamental values (string or number) in more complex data structures is a very powerful technique that many, many languages allow, and I would argue that the fact JavaScript can also do this is awesome.

(b) We could say that automatic coercion doesn't happen here, and that any non-string value must first be "cast" to an acceptable value.

parseInt(myCoolString,10); // throws error!
parseInt(myCoolString.toString(),10); // this is ok, because the object was coerced first, but it's certainly uglier!

// but, what about....
parseInt(""+myCoolString,10); // should string concatenation do the coercing?

Some would argue there should be coercion with string concatenation, so if you agree, I ask "why coercion here, and not for the param of parseInt()?" If you think no automatic coercion should occur, then there's a LOT of power across the language that you'd be eroding, and you'd be neutering much of what makes a dynamically-typed language attractive.

I think overall, there's far too many complex situations for us to go through with a check-list and say "yeah, javascript should allow coercion there" and "but no, it shouldn't be allowed there". Also, the inconsistency of the language would be far worse than it is now, because developers would have to know lots of complex rule-sets for when coercion is implicit, and when it must be done explicitly.

By contrast, all I've been arguing is that to effectively program in javascript the way it currently works, you only need to understand a few combinations of type coercion that are really unsafe, and avoid them. For instance, null + string is probably not safe, so avoid it. But number + string is pretty sensible, so allow coercion there.

There's been a lot of thought into this specific question about what type coercions are "safe" and not, and http://restrictmode.org goes a LONG way toward helping people swim in the deep end of the pool but make sure a lifeguard is nearby to keep things safe.

Given the choice between "always coerce", "sometimes coerce", and "never coerce", the "sometimes" and "never" options are very slippery slopes that make javascript more like other languages (Java, C, C++) which I like less, so it would make me like javascript less.

I think it's better to educate javascript developers on how to be more responsible with what they code, and how to avoid the pitfalls.

---

So, if we accept that coercion should always occur (if you don't yet, just stop reading...), there's still two other behaviors of the parseInt(0/1,19) example that we could still examine/attack to find something to blame. I'll cover those two in the next comment.

As I said in previous comment, beyond implicit type coercion, there's two behaviors at play we can examine: Infinity.toString() == "Infinity" and parseInt("Infinity",19) == 18.

The first behavior has lots of very powerful and useful applications in the general case, beyond the specific case. Let's say that the language defined:

Infinity.toString = function(){ return void 0; }

Is that "more correct" in your opinion? Or is

Infinity.toString() = function(){};

If it returns a something "not a string", then the language will still try to make it into a string (if that's what it was expecting from a coercion), so now it's left with the undefined value to convert. So, the can has been kicked down the road a bit, and now we ask if this is "more correct":

undefined.toString() = function(){ return "?"; } // what should it really return?

This line of reasoning really is asking, should these special complex natives not be able to be coerced to strings at all, because figuring out what that coercion should result in is too hard? If they had no toString(), and using them in a string context just resulted in an error, then how crippling would it be that I try to do:

var a = 1/0;
//...
console.log(a);

It turns out there's several places where I need a value to have a string representation for output purposes. It needs to do something sensible in terms of making a good visible output. Some values are easy, but some require special cases like this. I think Infinity.toString() == "Infinity" is the right default behavior.

If you use Infinity in places where a string is expected, it needs to give you the string "Infinity". Anything else would be nonsensical.

---

Should we blame parseInt("Infinity") for not seeing that it was passed the special string "Infinity", which probably came from something like 0 / 1 operation, and issuing a warning or error? What if I explicitly pass in the string (not from an operation or coercion), should parseInt() also squawk?

The whole definition of parseInt() is to try and find whatever number it can from left-to-right from the input string. If I pass in "123a", why shouldn't I get 123 back out? If I do parseInt("ff",16), I get 255 back, so why not parseInt("ffg",16)? Similarly, if I do parseInt("ii",19), I get 360, so why should parseInt("iim",19) fail?

---

Bottom line:

1. Infinity.toString() == "Infinity", and that's a helpful thing. We shouldn't "fix" that because it'd make many other things much harder.
2. parseInt("iadd",19) ==127332 is good, and so is parseInt("iaddvalue",19)==127332. To say the latter should be an error is to fundamentally neuter a powerful helper in parseInt().

To expound briefly on why parseInt("123a")==123 is useful, consider that some of the typical uses are:

parseInt("123px"); // 123 -- that's useful!
parseInt("123%"); // 123 -- that's also useful!
parseInt("123.5"); // 123 -- yep, useful
parseInt("123' "); // 123 -- still useful
parseInt("123      "); // 123 -- thanks javascript!
parseInt("123a"); // 123 -- yeah, i'm fine with that given all the above!

Again, I'm not arguing against type coercion. Hooray type coercion! I'm against retarded type coercion.

parseInt should throw an error if you send a number to it. parseInt(123) and parseInt(Infinity) and parseInt(1.23) make no sense. Anyone who has gotten there has made an error, and the function is lazy and wrong for not throwing an error. If you really want the behavior of parseInt(1.23), you can do parseInt('1.23') or parseInt((1.23).toString()). That way, you're not denying the programmer her awesome powerful ability to derive the number 18 with parseInt((1/0).toString(),19).

One way to say it is, "stupid programmer used unsafe type coercion." Another is, "stupid global function used stupid type coercion." In this case, both correct.

@bhudgeons
The problem with your assertion is that you're narrowly looking at the case of parseInt(123) vs parseInt('123'). Obviously, in the case of using literals (which hardly anyone ever does), wrapping it in quotes is "no big deal"(tm).

But, in reality, most code in a dynamically-typed language passes a variable to parseInt() whose value is set in one or more other places in the code. In fact, it's quite common for the value of that variable to get set in one of several different ways.

Sometimes it's a value that's already a number, sometimes it's a value that's still a string, sometimes it's a string that hasn't yet been santized (it's still "123px"). Imagine a reusable function that's supposed to do something with this variable, and he knows he can possibly get either strings or numbers.

In this scenario, because we're taking full advantage of dynamic typing and allowing a single variable to hold different "types" at different times, clearly some coercion/casting needs to happen.

So what we're really arguing about is where should this coercion happen. You're arguing it should happen in user-land code instead of at the native interface. I'm arguing that by having coercion happen at the native interface level, we get a whole bunch of benefits:

1. it's faster (less work to do to check the types of what comes in -- just allow native language coercion to happen as it will). also, you don't have to wrap parseInt(), so there's less abstraction, so it runs faster, if you know what you're doing and you don't pass unsafe types.
2. it's consistent (all interfaces allow the coercion, in all cases, instead of there being special cases where coercion doesn't occur, like this one specific case you're asserting).
3. it's cleaner code (compared to something like C++ where you have chains of crazy explicit type casting for each param you pass to a function) in user-land code, because we can rely on the native behavior of the language.

Again, in my view, this is a trading of "evils". Which evil is more evil?

-- a small set of type coercions create crazy results, so they must be avoided or used carefully.
-- devs have to learn lots of special cases for where coercions occur and where they don't, and under what circumstances, and in those cases where they don't automatically occur, the code-smell grows with all the C-like explicit casting crap.

Yea, I myself like the current implicit coercion mechanism in javascript. Wouldnt change anything with parseInt() neither.

Javascript is just way more flexible than other languages. That automatically makes it more errorprone. Thats why you find lots of WTF-examples for javascript. Other more restricted langs wouldnt even allow to run some questionable examples.

The question is, do we need this this much flexibility (and therefore errorpronenes). I would say yes, in such a dynamic and changing domain like the web, I dont want to be restricted by the language. One still can (and for large projects probably should) voluntary opt-in restrictions by using only certain programming patterns and thus opt-out possible errors.

Keyword is 'voluntary', still Javascript should stay that flexible imo. If more forced restrictions are needed (for special domains or personal leanings), there are alot more restricted languages around (Java, C).

The crazy results are either funny and deserving of ridicule, or produce annoyingly hard to diagnose bugs. As code size grows, it becomes increasingly hard for mortal programmers to reason about what they've written, not to mention what others have written. If I had written parseInt and saw the Infinity thing, I would call it a bug and fix it, because I don't like for my functions to produce silly results, no matter what the insane user throws at it. I'd either do my best to make my function handle odd corner cases like Infinity in a sane way, or I'd make the user of the function explicitly call toString() by throwing an error if the user supplied a number to a method that, by definition, exists to parse a string into a number. But that's just me.

Other languages (even statically typed ones) manage to do this stuff elegantly without overloading code with casting.

This discussion seems very focused on the oddities of parseInt(string,radix). ES5 took out the automatic octal mode, so parseInt("Infinity or other non-number") == NaN always. So we're talking about a specific case where you as the developer specified the radix. If you really must parse base 19 numbers, then I would hope you have a better understanding of parseInt. But if you just want base 10 numbers, use Number(string) or just +string. If you know there are units or something non-numeric tacked on, that's really the only time you need parseInt.

@bhudgeons
You said here (https://twitter.com/bhudgeons/status/221073881677570049) that you thought maybe parseInt("123a") should be an error, do you still feel that way given my comments above? If so, why?

If not, should parseInt("Infinity",19) be OK or an error? What about parseInt(""+(1/0),19)?

The latter one is interesting because the user is doing the coercion themselves and sending you a string (which happens to be "Infinity"), and they're asking for the base-19 parsing of that string, as much as possible.

Consider this specifically:

var a = 1/0;
// ...
parseInt(a,19); // you think this should throw an error, or be NaN or something?
parseInt(""+a,19); // what about this case?

I'm not sure I understand why you think those two calls should behave differently? Can you elaborate specifically on that example, to clear out the clutter from the rest of this thread?

To make the point of my question crystal clear, why would the presence of ""+ (or any other way you could force coerce Infinity to a string) indicate that the developer knew what they were doing, and they intended to send in the string "Infinity"?

Or, perhaps, your problem is not parseInt() at all, but that you think that Infinity should never be coerced in any operation, even in a string concatenation?

parseInt is fine the way it is. Without it you can choose to pass variables of any type and still have it function smartly. For instance, if your function accepted an argument to increase some display value, it wouldn't matter the type of what was being passed in (which is what Kyle is referring to):

var currentValue = 0;

var logIncreasedValue = function (value) {
    currentValue += parseInt(value);
    console.log( 'The new value is: ' + currentValue );
}

logIncreasedValue( 10 );
logIncreasedValue( '20' );
logIncreasedValue( { toString: function () { return 50; } } );

In the function a string, number, and an object are all passed in as arguments to the logIncreasedValue function. The parseInt is merely a protection mechanism against starting to do math with arguments that aren't numbers. You can also default the value to 0 in case the parsing fails. You can even use the unary + operator to coerce to number without even using parseInt:

var logIncreasedValue = function (value) {
    currentValue += +value || 0;
    console.log( 'The new value is: ' + currentValue );
}

I am not saying the language was designed to be able to "hack" together values for operating in this manner, but the functional and powerful dynamism of JavaScript has proven to be an elegant method for writing concise code.

@getify -- It's fine if parseInt("123a") doesn't return an error. In the tweet you referenced, I said that parseInt(123) should throw an error, and yes, I still think so. Likewise, in my opinion, it makes the function much better if

var a = 1/0;
parseInt(a,19);

throws an error. If coercion of any number value into its string value with toString, followed by a re-conversion of the resulting string to an int is what you want (which I can't imagine it would ever be), you can just do

parseInt(""+a,19)

or

parseInt(a.toString(), 19)

At the very, very, very least, parseInt should do something like

function parseInt(str,rad) {
    if (str === Infinity) { return Infinity; }
    ...
}

That would even make logIncreasedValue(Infinity); work correctly (ie, ==Infinity), instead of returning NaN (which, given how a normal person would expect such a function to work, is wrong).

It would also be nice if parseInt('Infinity') == Infinity [and, by the way, I guess you'd have to document that parseInt('Infinity',36) still == 1461559270678]

I can't quite get my head around how someone can look at parseInt(1/0,19)==18 and not laugh, much less think that it is preferred behavior, much less that it is "functioning smartly." I don't understand how fixing the method to produce results that are more mathematically correct yields a reduction of your programming freedom.

@bhudgeons

In the tweet you referenced, I said that...

I mistakingly put the wrong tweet-link, and have since corrected it. In the correct tweet, you said

I'd question the advisability of not returning an error for parseInt('i'm dumb',19)==18

So I was curious if you still felt that way. Sounds like you don't.

If coercion of any number value into its string value with toString, followed by a re-conversion of the resulting string to an int is what you want (which I can't imagine it would ever be)

No, that's missing my point. What is quite often (an easy scenario to imagine, as I explained earlier) "what [i] want" is to make sure that I get an int out, no matter whether it starts out as an int, or a string representing an int, or a string that is int-like on its left-hand side. You could rename parseInt() to makeIntNoMatterWhat() for the purposes of this discussion.

But the point is, most javascript devs expect that (because it's true everywhere else) if you have an int and you need to use it as a string (even if that use is to turn around and make it an int again!), there's no problem, because javascript coerces your int to a string quite nicely.

If in all other places in javascript, ints got coerced to strings automatically and perfectly, but in this one case, where I pass an int to a function that is expecting a string and that function wants to be an asshole and say "no, I won't auto-coerce for you. screw you.", THAT function would be wholly out of place in javascript.

I can't understand why that consistency point doesn't seem to matter to you? Why is the semantics of the name of the function overriding the desire to have consistency in how things are coerced?

I can't quite get my head around how someone can look at parseInt(1/0,19)==18 and not laugh, much less think that it is preferred behavior, much less that it is "functioning smartly."

I have said it before, and I'll repeat: what I like is that javascript is behaving consistently here (the coercion of a number to a string), just like using that number (aka Infinity) anywhere else in code that expects strings gives me, in fact, a coerced string.

The side effect of javascript behaving consistently here is that it creates a higher-order semantic "WTF" for you. That doesn't mean javascript isn't functioning logically (it is!), it means it's not functioning how you would describe "sensibly".

I prefer to look at the lower level behavior, rather than the higher-order composite side effect, for reasoning. The lower level behavior is quite reasonable; what's wrong is not that. What's wrong is that a developer is composing lower level behaviors in an unreasonable way, and expecting a reasonable outcome.

I don't understand how fixing the method to produce results that are more mathematically correct yields a reduction of your programming freedom.

parseInt() isn't a mathematical function, so it has no such notion of "mathematically correct" operations.

"Fixing" this "problem" would mean one of two things:

1. create an exception only for parseInt(), simply because it's name and the documentation imply some semantics which seems to override the importance of consistency of coercion behavior language-wide.
2. disable all such auto-coercions (maintaining consistency!) and throw the baby out with the bathwater, such that everywhere that I want an int to be a string, I have to manually cast it as such.

Both of those options are, IMHO, more evil than the evil of having to understand where coercion is "safe" and where it's "unsafe". The rules for safe coercion are so limited and relatively easy to learn compared to learning where all these rabbit-hole exceptions would be, I just can't understand how anyone with even a modicum of respect for the language would think that's a better path. But perhaps that's where the failing is, that I'm assuming respect where it's lacking. :)

Let me be slightly more formal with my assertion about the composability of underlying behaviors.

Let's call f() the function that turns an int to string, and let's call g() the function that turns string to an int (as much as possible, with LTR parsing).

There's an assumption I think being made that a "correct" language would ensure g(f(x)) == x. For some values of x, that's certainly true of javascript. But some values of x, which are still of type number, aren't composable like that. One such value is Infinity, another is NaN.

For that to be true, g() would have to have special-case behavior that is not only not present in the language, but if it were present, it would create even harder to "know" (aka, find/debug) behavior than we currently have.

Imagine g() were defined as:

• look for "Infinity", and assume they want the special Infinity numeric value parsed out (but wait, Infinity is not an int, it's a number, so oops... we have a contract violation).
• look for "NaN", and assume they want the special NaN numeric value parsed out (but wait, NaN is also not an int, it's a number... oops).
• look for "-Infinity", and assume.... oops
• ...

And then we'd have to consider whether we want to allow g() to operate case-insensitively or not.

And even if we had this behavior, we'd still have just as many possible WTF's, just of different substance. For instance:

parseInt("Infinity Broadcasting") == Number.POSITIVE_INFINITY  // seriously, wtf? this should be NaN
parseInt("-Infinity Broadcasting") == Number.NEGATIVE_INFINITY

And then, we'd have to consider whether this special behavior was true no matter what radix/base we pass to parseInt(). For instance, if I say, parseInt("Infinity",26), would I rather get Number.POSITIVE_INFINITY, or would I instead expect 224651640?

I have no "respect" for any language. I'm not even sure what that means. Technology decisions are tradeoffs. The choice of one language over another is a matter of choosing the best tool for the job at hand. I absolutely respect the toolmakers, but the tools are just tools. If you point out a flaw with my tool, I may argue that said flaw is a feature, but neither my tool nor I shall feel disrespected.

I guess that parseInt(1/0,19)==18 is just my own personal semantic WTF. I'm sure if you're experienced enough with JavaScript, you can look at a function that (a) purports to produce integers that match its parameters, (b) accepts Infinity as one of the parameters, and (c) produces the number 18, and use it as an example of the greatness of JavaScript.

Many of us continue to shake our heads, and struggle to understand. Perhaps one day we will become enlightened. Then shall we understand parseInt(1/0,19)==18. Until then, we trudge along in the darkness of our stupidity.

@bhudgeons
parseInt(1/0,19)==18 is clearly a semantic WTF... for pretty much everyone, myself included. There's never been an argument about that.

There are plenty of other semantic WTFs too. My personal "favorite" is typeof NaN == "number".

The question has been, is the language "flawed" by allowing that (or rather, not ensuring some yet-to-be-well-defined alternative)? And more importantly, if we were to consider changing the language to "fix" the "flaw", would we REALLY be better off, or is that just a "grass is always greener" conundrum?

I've been trying to illustrate that all the alternatives are worse. You're not in the "darkness of stupidity" because you disagree. You just value different things from the language than I do.

:)

I woud use valueOf here instead of toString.