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

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.