That would result in char being printed out as an int value, e.g. 65
instead of 'A', which is inconsistent with std::format("{}", 'A'). If there
is a generic version of std::to_string then it should produce the same
result as std::format, no?

By the way, in your earlier email you mentioned the formatable<char>
concept to constrain a hypothetical generic version of std::to_string. Does
this concept exist already, and if so, why isn't it used on std::format
itself, which as far as I can tell, is currently unconstrained?

On Thu, Oct 5, 2023 at 9:52 PM Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Thu, 5 Oct 2023, 12:53 Jonathan Sweemer via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> I would say yes, if the general consensus is that std::to_string is
>> useful and should not be deprecated, then at least it should be made more
>> generic.
>>
>> The current list of overloads for std::to_string seems a bit arbitrary
>> and incomplete to me, with char being the most error-prone example, as it
>> happily binds to the overload taking int.
>>
>> If you know you're dealing with ints, then I agree that std::to_string
>> provides a more simple syntax for converting to a string, but in any
>> generic code you either have to use std::format (i.e. forget about
>> std::to_string), or do something like the following to delegate between the
>> two:
>>
>> template<typename T>
>> concept to_stringable =
>>
>
> requires(const T& t) {
> { std::to_string(t) } -> std::same_as<std::string>;
> };
>
> std::is_same_v<T, int> ||
>> std::is_same_v<T, long> ||
>> std::is_same_v<T, long long> ||
>> std::is_same_v<T, unsigned> ||
>> std::is_same_v<T, unsigned long> ||
>> std::is_same_v<T, unsigned long long> ||
>> std::is_same_v<T, float> ||
>> std::is_same_v<T, double> ||
>> std::is_same_v<T, long double>;
>>
>> template<typename T>
>> auto generic_to_string(const T& t) {
>> if constexpr (to_stringable<T>) {
>> return std::to_string(t);
>> } else {
>> return std::format("{}", t);
>> }
>> }
>>
>> But the to_stringable concept is very brittle to maintain, because new
>> overloads might be added in future versions of the standard, so a truly
>> generic version of std::to_string would be more desirable in my view.
>>
>>
>> On Thu, Oct 5, 2023 at 4:56 PM Giuseppe D'Angelo via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Il 04/10/23 22:38, Victor Zverovich via Std-Proposals ha scritto:
>>> > At the very least std::to_string is a useful shorthand notation for
>>> > std::format for numeric types.
>>> >
>>>
>>> But this prompts the question: would it would make sense to have a
>>> overload `to_string` taking just any formattable type?
>>>
>>> Thanks,
>>> --
>>> Giuseppe D'Angelo
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>