On Thu, 5 Oct 2023 at 14:14, Jonathan Sweemer <sweemer_at_[hidden]> wrote:

> 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
>

That was a typo for formattable, but yes it's exists since C++23.


> 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?
>

What would be the advantage of constraining it? There's only one
std::format function, so either it compiles or it doesn't. You don't need
to select between different overloads based on constraints. Checking a
constraint would just make compilation slower.

Constraining it would allow you to test whether std::format can be called
for a given argument type, but you can already use std::formattable to do
that (which would be faster to compile than testing whether a function
constrained with std::formattable can be called).

But the real answer is probably just that the concept was added in C++23
and std::format was added in C++20, so it couldn't have been constrained
with a concept that didn't exist yet. I don't see a compelling reason to
add the constraint now.


>
> 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
>>>
>>