"{:?}" for 0. is 0 instead of 0.

[yongqli]

This code:

fn main() { 
    println!("{:?}", 0.);
}

produces 0, but I would expect 0.. This breaks the convention of Rust source code.

https://play.rust-lang.org/?gist=e1f1c703b2c582ddc3c3&version=nightly

[jonas-schievink]

There's no way to distinguish between 0f64, 0. or 0.0 or any other representation of 0 at runtime.

IIRC The current float pretty printer just uses as many decimal places needed to prevent rounding errors from reading it back. However, I don't think it's a bad idea to always print floats unambiguously (ie. always print a decimal point, even when not needed for accuracy).

[yongqli]

Yes, I would like it to always print 0. so that I can read back the outputted value as valid rust source code.

[hanna-kruppe]

This was discussed before, and IIRC rejected because of backwards compatibility concerns. Or maybe I'm mistaken and it was only using exponential notation by default that was rejected. See #24612 for some context, I'm sure there's more.

[hanna-kruppe]

Also, do I understand correctly that your use case would require all floats that can be printed as integers to include a trailing .? I think Rust's Debug doesn't even try to follow the guideline (used for example by Python for repr(), and even there it's just a guideline) that the output should be valid to copy & paste into code. So if this is your sole motivation, I think it's misguided.

[oli-obk]

just use {:.1} as a format specifier to guarantee at least one digit after the dot.

[bluss]

I'll go out on a limb and say that {:#} (alternate Display formatting) for floating point could always print the decimal point (Debug too?). It's only usable directly however; not reachable when the number is part of a struct.

This issue does of course relate to all whole number floating point values, not just zero.

[steveklabnik]

/cc @rust-lang/libs

[dtolnay]

I agree that the Debug representation of a float should clearly look like a float. 0u64 and 0f64 should not have the same {:?}. My preference would be for 0.0 but I could live with 0..

Marking feature-accepted as I would be prepared to consider a PR fixing this, but if the PR turns out to be controversial then we may ask for an RFC.