>> I think you're saying that having the "guaranteed round-trip" precision
>> would be useful for C, so we should come up with something that is printf
>> compatible. How about the letter "r" for "real" (or "round trip" or
>> "robust") instead of "z"? (Honestly, I don't really care what letter it
>> is, but having something mnemonic would be ideal.)
>That makes sense, but only so long as the same functionality doesn't apply to
>'f' or 'e'. Is there such a thing as exact round-trip for those two? If so,
>you want a modifier, not a type

Good points. According to cppreference, https://en.cppreference.com/w/cpp/utility/to_chars, the "function recovers exactly" applies to overloads 3 and 4. (The wording is bad, but it couldn't possibly apply to overload #5 which has user-specified precision.)

According to P0645 and cppreference: e, f, and g always specify a precision and use overload 5, meaning they cannot support the round-trip. Only <none> uses overload 3. You are correct that e and f could also have a flag which forces the use of overload 4.

The use of a flag was basically what I labelled Possibility #2, but I wasn't sure the best way to encode it. I proposed {:.g} originally. A better possibility is to use something like the '#' alternative form option. Perhaps @, so {:@g} or even {:@} would then give the same result as {}? And, {:@e} and {:@f} would be legal. (Again, I really don't care what character is used, but = and $ are unavailable.) As far as I can tell, "%_at_g" would work fine in printf, too.

FYI, there was a proposal to fix some corner cases, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1652r0.html. I've copied the authors on this conversation as they probably are well-versed in the issues faced here and may have other ideas on encoding.


Rob Lefebvre
Senior Software Architect, Keysight Technologies