On Wed, 4 Oct 2023 at 14:08, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 10/4/23 15:26, Jonathan Sweemer via Std-Proposals wrote:
> > Hello,
> >
> > I recently came across P2587 "to_string or not to_string", which has
> > been accepted for C++26, and I am wondering whether there has since been
> > any attempt to deprecate std::to_string?
> >
> > The motivation would be to consolidate on std::format, which
> > std::to_string is now (as of C++26) defined in terms of, thereby making
> > the standard library marginally smaller and easier to teach (in my
> opinion).
> >
> > If this is a stupid idea, then can you kindly inform me of the role that
> > std::to_string is intended to play in the language for C++26 and beyond?
>
> Please don't deprecate std::to_string. I do not want to have to use
> std::format whenever I need to stringify an int. Its interface is too
> cumbersome for such a trivial task.
>

> Also, even if std::to_string is defined in terms of std::format (I
> haven't checked), I sure hope that it isn't implemented that way, as
> that would be very inefficient. Specifically, std::to_string does not
> need to parse any format string in order to produce its result.
>

A good std::format implementation will have an optimized fast path for
"{}". (GCC's std::format has that, but only in my Git tree, I haven't
pushed it upstream yet.)

Of course std::to_string can avoid even the branch needed to take that fast
path, but if std::format("{}", x) is already optimized then implementing
std::to_string(x) as return std::format("{}", x) will be quite efficient.

I think the main argument against deprecation is that there's nothing wrong
with std::to_string (at least not for integral types, and since C++20 it's
good for floating-point types too). People have been using std::to_string
with integers since C++11 and I see no reason to break their code just
because we've added another way to do that same thing.