Hector Martin

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.

Sure, there are ways to get the full value out. My point here is that the default behavior is unintuitive and misleading in this particular case. Nobody expects an integer to have been rounded. Having to deal with the 53-bit ceiling is bad enough; toString hiding it is worse!