Fmt: Floating-point formatting defaults differ from iostream/Boost.Format

[dalle]

The default is "g" in std::iostreams and boost::format. This is also the default in .NET-based languages (C#, F#, VB.NET), Rust, R.
The default is "g with at least one digit past the decimal point" in fmt. This is also the default in Python.

This can lead to hard to find bugs when porting from one of these libraries to fmt.

The rationale for the default in fmt is that;

The default gives you round trip guarantees while g does not.
_Originally posted by @vitaut in https://github.com/fmtlib/fmt/issues/1889#issuecomment-696733490_

May I ask how is "1.0" more _round-trippable_ than "1", given a floating-point context for the value of 1?
The documentation does not mention round-trip guarantees for the {} format specifier, perhaps it should?
May I suggest another format specifier for round-tripping, what about {:R}?

But as per usual, there are almost uncountable different ways software engineers prefer their floating-points to be formatted by default. :joy:

[vitaut]

May I ask how is "1.0" more round-trippable than "1", given a floating-point context for the value of 1?

This is not what I was saying. I was explaining what is the main difference between the default format and g.

At this point the format is fixed for compatibility with std::format (and Python). If you want compatibility with printf's %g, please use the g format specifier.

[dalle]

In lack of having access to the C++20 standard, I read https://en.cppreference.com/w/cpp/utility/format/formatter which currently state the following available floating-point presentation types;

none: If _precision_ is specified, produces the output as if by calling std::to_chars(first, last, value, std::chars_format::general, precision) where precision is the specified precision; otherwise, the output is produced as if by calling std::to_chars(first, last, value).

That lead me to test what std::to_chars(first, last, 1.0) would produce, and it produce "1" on my system. That may be an error though, and cppreference isn't always 100% standardese either.

[vitaut]

What do the specs say about to_chars?

[vitaut]

to_chars specs are somewhat vague but it looks like the intent is to not emit the trailing zero, so I changed the default accordingly in https://github.com/fmtlib/fmt/commit/2d4fde3a2edee4af40ecc863082197860513e054 to make it consistent with std::to_chars (and therefore std::format). It is possible to get trailing zero and decimal point with #. Thanks for reporting.