Hector Martin

Yes, the ECMAScript spec says toString must be implemented in this (broken) way. This is insane, and no other sensible language does this. It is misleading and wrong. https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type …

Ultimately this is a problem of the principle of least surprise. To any reasonable human, a string of digits with no decimal point is an *integer*. However, to JavaScript, it's a *float*. JS is abusing this point to produce unexpected results from toString.

Yes, the output string equals the float when spat back into a JS interpreter, but that's besides the point. It's not what a *human* expects. This is like the people complaining about things like undefined behavior in C. Except the latter is at least often useful for performance.

This stuff hurts people trying to learn the language, because instead of doing what's natural and obvious, things will work until suddenly they don't. The person learning will be bit by bugs, and will be told "that's just the way it is", but it shouldn't *be* that way.

You work on TC39, so suggestion: change toString so that any numbers ≥ 2⁵³ or ≤ -2⁵³ are stringified in e-notation, or, alternatively, with the full integer digit expansion and a trailing ".". This makes it clear when precision is limited, without phantom/incorrect digits.

I doubt that’s feasible. I bet it would break lots of existing code. @littledan

toString always outputs a string which, when parsed as a Number, rounds to the same value. There are multiple strings which would round to the same Number. I think ending it with a bunch of 0's is often more intuitive, which would motivate that choice.