#fmt uses wrong default precision for float

[brson]

fmt("%f", 5.82) yields "5.82". Other printf's yield "5.820000".

[nikomatsakis]

Not sure that's a bug.null

[lht]

The default precision is 6. Looks like the trailing zeros are chopped.

input	Rust	C
5.821010	5.82101	5.821010
5.8210	5.820999	5.821000
5.821	5.820999	5.821000
5.82	5.82	5.820000
5.0	5	5.000000

[boggle]

float::to_str needs an overhaul. There is no support for NaN, +inf(inity), -inf(inity) and probably should use float::frexp instead of substraction and casting around (and perhaps get rid of that weird pow_uint_to_uint in the process). This likewise extends to from_str (don't know, needs checking).

Additionally it would be nice to write this in a f32, f64 agnostic way, or at least move it from float into two copies in f32, f64. Probably this should wait until we have typeclasses in which case this may better be done using a "float number builder" interface which would be passed to "float::to_str" to build a number of the correct type (alternative would be to use bigints when they get implemented)

In general, fmt probably should be rewritten for use with typeclasses so I'd say this ticket should remain on hold until they land but then there's a lot to do here.

[brson]

@nikomatsakis Did your first comment indicate that you think we should not follow printf here? If so, I am starting to agree. printf's behavior is not really what I would expect.

[emberian]

Still relevant, although it does handle inf and NaN now.

[catamorphism]

Sad, but not a milestone blocker.

[bstrie]

Not sure I agree that we need to exactly imitate C-style format string defaults, especially since we no longer use C-style format strings and also because we've now actually implemented the ability to specify the precision when printing:

print!("{:f}", 100.000000004f64);  // 100
print!("{:.9f}", 100.000000004f64);  // 100.000000004

That first one might be a little worrying... but that's probably a different bug anyway.

[huonw]

cc #6220

[brson]

I haven't followed this in a long time and don't know what the status is, but now that we're not explicitly copying printf, if our current behavior is sane, then I think that's just fine.

[alexcrichton]

I agree with @brson that we're different enough from C that I don't think that this matters that much. We have different semantics, but that just means that we have our own semantics.

We're not losing functionality, you can still specify precisions that you want. For this reason, I'm going to close this. New bugs can be opened for any shortcomings found in our float formatting code.