Or introduce a std::to_fstring as abbreviation to create a formatted string with no need to regard backwards compatibility.   -----Ursprüngliche Nachricht----- Von:Jonathan Sweemer via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 09.10.2023 12:41 Betreff:Re: [std-proposals] Should std::to_string be deprecated? An:std-proposals_at_[hidden]; CC:Jonathan Sweemer <sweemer_at_[hidden]>; Giuseppe D‘Angelo <giuseppe.dangelo_at_[hidden]>; Right, if backwards compatibility for std::to_string(char) needs to be preserved (for better or for worse) then this exercise becomes a lot less attractive in my opinion.  But if I understand correctly, P2587 somewhat broke backwards compatibility for floating-point arguments, so where do we draw the line? (I'm genuinely curious, as I am not an expert.)  Alternatively, what if we simply added something to the C++ Core Guidelines to the effect of "use std::format for new code, and migrate from std::to_string to std::format if possible"?   On Mon, Oct 9, 2023 at 6:06 PM Giuseppe D'Angelo via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On 09/10/2023 10:03, Jonathan Sweemer via Std-Proposals wrote: > > template<typename T> > auto to_string(T&& t) { >    return std::format("{}", std::forward<T>(t)); > } > > This is essentially the same thing that Grzegorz suggested as well, but > personally I prefer putting it in std::to_string because if it's not > going to be deprecated, then it should at least be made more generic. That's what I was thinking as well. The big concern I have right now is that we need to special-case arithmetic types anyway for backwards compatibility. Right now there's no overload for char/wchar_t, so they fall back into std::to_string(int); but those do have different meanings when formatted via std::format. Extended fp types may also constitute a problem (they're supported by std::format, but not by std::to_string; the above snippet may change their output). Given the only solution that is ever going to be accepted will be to keep the current behaviour, this actually makes std::to_string way less desirable to be used by generic code, possibly killing this whole exercise. My 2 c, -- Giuseppe D'Angelo -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals