Consider outputting a `.0` suffix for FP values without a fractional part

[rprichard]

Regardless of the outcome of issue #1074, we should consider suffixing .0 for FP strings with no fractional part. A bare numeric literal with no exponent or decimal is typically an integer literal, not a float literal. This presents issues in various ways:

• -0 looks strange to programmers. Only the floating-point zero can be negative.
• -0 is much less likely to round-trip than -0.0.
• Sending a value from Rust to a dynamic language with a separate integer type (e.g. Python / Ruby / Racket) is hazardous. The number may be parsed as a float or an integer, and if the code, for instance, divides numbers by 2, there may be unexpected truncation.
• Debug's recent RFC 640 indicates that, "when it is feasible to do so, debugging output should match Rust syntax." While, say, 4.0 is a valid FP value in Rust, 4 is not.

The .0 suffix is reasonably widespread, though not as ubiquitous as minus zero. Exceptions include C# and Go. OCaml prints a bare . suffix, as in 42..

Our JSON serializer suffixes .0 to the result of Display. I feel that this should be the default behavior.

It might also make sense to add the .0 suffix even for floats with an exponent, though the need is less clear. It is somewhat more consistent, and it matches Haskell, Java, and Ruby. Thus far, I know that Erlang's REPL does not accept 1e30 but does accept 1.0e30. I expect most systems to treat 1e30 and 1.0e30 equivalently.

[pnkfelix]

I am strongly in favor of this.

[ftxqxd]

I’m in favour of adding .0 for when a float is formatted with Debug, but I’m not so sure about Display. Which trait implementation(s) does this issue propose modifying?

[rprichard]

I propose modifying both Display and Debug. Conceivably we could also modify LowerExp and UpperExp, but the interoperability benefit there is (I think) much smaller.

[ftxqxd]

Display is intended for user-readable strings. I don’t think that any of the arguments in the issue description apply to strings that will be read by users who aren’t necessarily programmers. In a normal/non-programming context, 1 and 1.0 are usually completely equivalent, so it just seems unnecessary to add the .0.

[rprichard]

Display is intended for user-readable strings.

I go into a lot more detail in #1074, but I don't think this is a very solid rationale. FP numbers are not generally readable to non-technical users (e.g. 1e100, 0.30000000000000004, NaN, +Infinity), and in any case, Display and to_string are predictably being used for JSON and CSV serialization.

FWIW, Racket appears to have something similar to our Display-vs-Debug distinction. It has display-vs-print functions. print quotes string literals, whereas display does not.

display mode prints core datatypes in a more “end-user” style rather than “programmer” style; for example, a string displays as its content characters without surrounding "s or escapes;

Nevertheless, its display function always outputs either a decimal point or an exponent, and it also outputs -0.0.

[nagisa]

In favour.

[scottmcm]

This happened for Debug in https://github.com/rust-lang/rust/pull/46831 :tada:

Can this be closed, or are people still wanting this for Display?