On 10/4/23 16:14, Jonathan Wakely wrote:
>
>
> On Wed, 4 Oct 2023 at 14:08, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto: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.

Performance is one part of the issue, the other one is code size. Even
if there is a fast path, you still have to link the entire
implementation of std::format.

I would say, a good implementation could share low-level bits of
implementation between std::to_string and std::format (e.g. the part
that formats an int could be used internally by both mechanisms when
they deal with ints), but I don't think simply forwarding from one to
another is a good idea.