Add IEEE 754 compliant fmt/parse of -0, infinity, NaN

[workingjubilee]

This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.

This PR follows from discussion in rust-lang/rfcs#1074, and closes #24623.

The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output -0 but output -0.0 here.

While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the + fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).

There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.

[rust-highfive]

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

[KodrAus]

We briefly discussed this in the recent Libs meeting and felt that format!("{:+}", -0) producing +0 was definitely a bug that we should fix.

It turns out the question of always printing -0 as -0 instead of 0 in the Display impl is indeed controversial! The fundamental question is whether we should aim for strict IEEE 754 compliance for the default Display implementation on floats. There were some concerns that we're somewhat locked in to the current behavior. Debug should absolutely be compliant though.

Since this turned out to be a bit of a bigger topic than we really had synchronous time for, I think we should try revisit it in more detail with a picture of what a roadmap towards compliance would look like for float Display and how that changes assumptions made by consumers of it.

[crlf0710]

Triage: So i created #79490 to tracking the controversal part, and i'll mark this as blocked on the decision of that issue.

@workingjubilee I think you can go ahead and split out PRs for the non-controversal part of this (Debug, fixing {:+}, etc).

[workingjubilee]

To reply to the stability concerns:

0. This is being proposed as fix in the standard library's implementation of the f32 and f64 types, so it is not automatically subject to Rust's stability guarantees as I understand them per RFC #1122.
1. Further, Display impls do not have a consensus on their stability per Decide on stability of Display output for libstd/libcore/etc. types #72676.
2. And floats already have other extant difficulties with round-tripping well, per Float parsing can fail on valid float literals #31407, which means that anyone relying on this behavior is likely already broken.
3. Further, as Rust defaults to an IEEE754 noncompliant approach here, assuming that this is not already broken but in a silent manner for users is largely incorrect.

My apologies, I know this PR has been open for a while without much remark, but that is because I am not interested in pursuing this line of inquiry further if this is in fact a reason to turn this PR down. Accordingly, I will not be splitting the changeset. From my perspective, either Rust has IEEE754 floats which behave in the expected way, in accord with the standard, or it does not. If it does not, then what the standard says about parsing NaN and such is equally moot.

[programmerjake]

3. And floats already have other extant difficulties with round-tripping well, per Float parsing can fail on valid float literals #31407, which means that anyone relying on this behavior is likely already broken.

Well, #31407 (comment) seems to imply that non-NaN floats are intended to round-trip on using Display and it is likely not broken for non-zero finite numbers.

[bors]

☔ The latest upstream changes (presumably #78259) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

We discussed this in the @rust-lang/libs meeting this week. We had consensus that changing floating-point printing to print the negative sign on -0 seems reasonable. We don't expect that to cause a problem in practice.

I'm going to go ahead and start a libs FCP. Please go ahead and update the PR to apply without conflicts.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @KodrAus
• @dtolnay
• @joshtriplett
• @m-ou-se
• @sfackler

Concerns:

• case insensitivity resolved by Add IEEE 754 compliant fmt/parse of -0, infinity, NaN #78618 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[dtolnay]

One thing I don't see called out in the discussion above or any of the linked issues is the case lenient parsing in this PR, e.g. "inF".parse::<f64>() -- before: Err(ParseFloatError { kind: Invalid }), after: Ok(inf). Is there a reference that justifies that behavior change?

@rfcbot concern case insensitivity

[joshtriplett]

@dtolnay From IEEE 754-2008 (I don't have 2019 available), "5.12.1 External character sequences representing zeros, infinities, and NaNs":

Conversion of external character sequences “inf” and “infinity” (regardless of case) with an optional preceding sign, to a supported floating-point format shall produce an infinity (with the same sign as the input).

Conversion of external character sequences “nan” (regardless of case) with an optional preceding sign, to a supported floating-point format shall produce a quiet NaN.

[dtolnay]

Thanks, that seems quite clear.
@rfcbot resolve case insensitivity
@rfcbot reviewed

[bors]

⌛ Testing commit e8dfbac with merge aef1140...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing aef1140 to master...

[namse]

Is there any fmt option to remove - sign for -0? I couldn't find it from (docs)[https://doc.rust-lang.org/std/fmt/index.html#sign0].