Hector Martin

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.

If you'd like to see the fun floating point bits, if you're trying to learn how floats work, you can do that with Number.prototype.toPrecision, toExponential, toFixed, which omit the logic to put 0's at the end.

My issue is the lack of any evidence that the number is a float; that rounding occurred. JS is in the awkward position of using floats for the use cases of ints. Presumably this drove the decision to have toString output just digits when the float is an exact integer value.

But then toString goes and *rounds* larger ints - at which point they're not floats trying to be ints any more - yet it still outputs just digits. And that is just confusing and messy.