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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>