But a uniformed interface of format seems more easy to manage instead of
using overload to implement this kind of unity. Just my stupid thinking.

On Wed, Oct 4, 2023 at 09:08 Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, 4 Oct 2023 at 13:26, 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?
>>
>
> P2587 was only very recently approved, there hasn't been much time since
> then for anything to happen.
>
>
>
>>
>> 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).
>>
>
> std::to_string(1234) seems simpler than std::format("{}", 1234) to me.
>
> And std::to_wstring seems a bit more explicit about what it's creating
> than std::format(L"{}", 1234) is.
>
>
>>
>> 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?
>>
>
>
> P2587 notes:
> "In addition to fixing the broken behavior for floating point, this
> proposal enables an easy and natural extension of std::to_string to other
> types via std::format (not proposed in this paper)."
>
> That seems worth exploring to me. We already have to_string overloaded for
> stacktraces as well as arithmetic types. I can see some benefit to defining
> a generic std::to_string like:
>
> template<formatable<char> T>
> string to_string(const T&);
>
> template<formatable<wchar_t> T>
> wstring to_wstring(const T&);
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>