AW: [std-proposals] Should std::to

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