Ah yes, because one std::stringstream isn't enough.

Em qua., 4 de out. de 2023 17:03, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:

> On Wed, Oct 4, 2023 at 1:26 PM Jonathan Sweemer via Std-Proposals
> <std-proposals_at_[hidden]> 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?
>
>
> How about having a new class:
>
> template<class CharT, class Traits = std::char_traits<CharT>,
> class Allocator = std::allocator<CharT> >
> class easy_basic_string : public basic_string<CharT, Traits,
> Allocator> {
> . . . . .
> };
>
> which has operator overloading so that you can simply use "+" to
> append a number to a string, like this:
>
> easy_string str("My name is Frederick and I have ");
> str += 6;
> str += " pet axolotls.";
>
> Also, add a paragraph to the Standard that says you can safely cast a
> 'basic_string&' to an 'easy_basic_string&'. It wouldn't be out of the
> ordinary to give special treatment to a type like this -- we already
> have special rules for std::complex.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>