-0.0 should format with a minus sign by default

[rprichard]

I think negative zero should be formatted with the minus sign preserved by default.

Issue 20596

Issue #20596 restored the sign for Debug but not for Display, because "for users, negative zero makes no sense." I feel this is a poor rationale:

• We don't know that the user is non-technical. For exponent-form, the user might very well be technical.
• FP is inherently non-user-friendly. Printing large and small numbers accurately and concisely requires exponent form (issue #24556) which may be unfamiliar to some users. We must also print [+-]Infinity and NaN.
• The formatter traits are used for more than UI output. to_string is Rust's canonical string representation. It is used to serialize a float for JSON. {:10} is used to serialize floats for CSV output.

The issue indicated that the CSS serializer could instead use Debug. There are problems with using Debug for FP serialization:

• Debug is inflexible. It should be fixed per issue #24556 to use minimal sufficient precision, but searching for this representation is non-trivial. For efficiency, familiarity, or interoperability, programs might want the exponent form {:1.8e} for serialization (for f32). This format mirrors the %1.8e format in C and other languages, but whereas C round-trips every value, Rust round-trips every value but minus zero.
• Debug is for debugging. Serialization formats need to be stable and documented. We would need to document Debug's output and guarantee its backward compatibility.
• Display and to_string are the default conversion APIs, so if the default suppresses -0, libraries will take this as a cue that the Rust ecosystem ought to suppress -0. In other words, it is unclear that the existing JSON and CSV serializers will change to Debug. Perhaps this is the intent; it's unclear. Outside Rust, the JSON serializers I've tested for Python, Ruby, Java (gson), and Go all output minus zero.

It is surprising that {:+} prints +0, while {:+?} prints -0 for the same number. They appear to contradict.

Other languages

Hiding minus zero makes Rust inconsistent with many other languages. Languages that show it include: C, C++, Go, Haskell, Java, Lua, OCaml, Perl, Python, Racket, and Ruby. As a systems language, it makes sense to do the same thing as C/C++, but even common Unix scripting languages show the value.

Go and Perl: the default print hides minus zero, whereas Perl's printf and Go's fmt package show it. Go's print outputs floats using the simple format [+-]N.NNNNNNe[+-]NNN; it's not trying to be user-friendly or sufficiently precise.

JavaScript hides minus zero, but it has no separate integer type. If a language must choose between preserving the illusion of an integer type or representing IEEE-754 precisely, it's reasonable to choose the former. Rust, on the other hand, has FP types. Moreover, even JavaScript's choice isn't obvious—Lua lacks integer types but still prints -0.

C# hides the minus sign.

Neither JavaScript nor C# have a built-in printf-style interface, nor do they display -0 with a + sign.

cc @rkruppe @lifthrasiir @aturon @Diggsey @SimonSapin

[nagisa]

I feel pretty strongly about this and believe we should not display sign for minus zero for Display by default.

It is surprising that {:+} prints +0, while {:+?} prints -0 for the same number. They appear to contradict.

I filled rust-lang/rust#24623

[Diggsey]

I'm not too hung up on which is the default behaviour, but I'd at least want to have a way to print a float such that it look like a true real number, ie. never display a sign for +/-0.

Generally, if I see +0 or -0 in a UI, I'm going to think that it's actually just a very small number which is zero when rounded but actually does have a sign, whereas with no sign it's obvious that it's actually zero..

[rprichard]

I'm fine with adding some way to round -0 up to +0 during formatting. format_args! accepts a - flag that is currently unused; perhaps it's an option. It would be nice to see how this problem is solved in the languages that print -0.0.

It's not quite reasonable to expect Display to show a non-technical-friendly output. It can (or should) print values like 1e100, 0.30000000000000004, NaN, +Infinity. It doesn't print the first two currently, but issue #24556 suggests we do. Assuming we do, I suspect we really need something like %f to restore decimal format. At one point, we had a Float formatter trait. I think it was removed during the stabilization effort and/or the Show -> Display/Debug split.

We also implement Display for types like Ipv6Addr, even though non-technical end users likely cannot read an IPv6 address.

Python, Ruby, and Racket each have a to-display-string versus to-debug-string facility (__str__ vs __repr__, to_s vs inspect, display vs print, respectively). They use -0.0 in all six cases.

Issue #24624 illustrates the problem with using Debug as a serialization format -- the Debug format does not seem stable.

[nagisa]

I think somebody misrepresented what Display does somewhere. It is supposed to be implemented for types which have an obvious, widely accepted string representation. This includes numbers, IP address and port pairs (because there exists a widely accepted convention on how to represent them as a string) and obviously strings themselves.

It has nothing to do with end users whatsoever. Or at least didn’t when it was still called String.

[rprichard]

I suppose the term is "user-facing" rather than "end-user". It's from RFC 565. It also includes this bit:

Require use of an explicit adapter (like the display method in Path) when it potentially looses significant information.

[bombless]

I like this idea but 0.0f64 == -0.0f64 looks a bit weird.

[lilyball]

FWIW, Swift has a distinction between Printable and DebugPrintable (which seems roughly equivalent to our Display vs Debug), and for floating-point values it displays -0.0 for Printable (it renders identically with toString() vs toDebugString() in fact). Curiously, NSNumber renders it as -0 instead (no decimal).

My initial reaction to this was a knee-jerk "no it shouldn't!" but I think it actually should. @nagisa is correct, Display is not defined as "the correct string representation to present to end-users". It's merely defined as the semantic string that represents a value (and in fact the std::fmt docs say "fmt::Display implementations assert that the type can be faithfully represented as a UTF-8 string at all times."). In light of that, I think -0.0 is absolutely correct here. If you want to present numbers to end-users you need to use a facility designed for that. Although I would support the addition of a :f modifier to fmt that tries to render floating-point values in a "simpler" form (i.e. drop the sign on -0.0, and drop any trailing 0s, which means for a .0 drop the decimal entirely, and when a precision is given, trim off trailing zeros, which would let me use "{:.6f}" to format a float for human consumption without having "too much" precision).

An alternative would be to use the # flag for floats to mean "precise representation", i.e. include the - on -0.0, and double-check how we handle edge cases like subnormals (how do we render those today?). But I don't think this is the ideal approach.

[aturon]

I don't have a strong opinion here, but I largely agree with @kballard's analysis: you should probably be using an adapter or modifier or some other facility to tailor the output of things like floating point numbers if you're going to display them directly to a user.

cc @alexcrichton @wycats

[alexcrichton]

I also have pretty few strong opinions in this area.

[wycats]

My feeling is that -0.0 is not a concept that "humans" (or even many programmers) understand, so if you're formatting it for human consumption, leave off the -. In other words, I would expect it to be there in Debug, but not Display.

[hanna-kruppe]

-0.0 may be a confusing concept, but it is a reality of the hardware and software we work with. While it's mostly interchangeable with +0.0 (arithmetic, comparisons) it does make a difference often enough:

• x / -0.0 is negative infinity, which naturally has far-reaching consequences.
• sign_num(-0.0), is_sign_positive(), etc. consider it negative which can lead to different results in code that works with the signs of numbers in complicated ways.

Therefore, I think it's helpful to point out negative zeros as clearly as possible. I'd rather have a small number of people slightly confused or amused by the "meaningless" sign than a small number of people waste hours chasing a stupid bug caused by a negative zero. It doesn't even matter if they know that there is such a thing as negative zero, even an IEEE-754 expert can be mislead if their debugging output indicates positive zero.

Aside: If {} prints 0.0 for negative zero, I think that means it treats it as positive, and so {:+} would print it as +0.0 for consistency. Thus even a sign-aware programmer can be mislead by using {:+} and thinking that takes care of negative zero.

[erickt]

I share @rkruppe's view. This would be a hindrance to doing numerical / scientific computing in Rust. I would prefer there to be an option to suppress printing -0.0 if that's desired. Also inconvenient for serialization, as I expected that float.to_string() would do the right thing here for serde json.

[bombless]

Maybe we can add {:f} formatter to control floating point number formatting.
See also rust-lang/rust#24556 (comment)