Date: Thu, 5 Oct 2023 20:53:07 +0900
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 =
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
>
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 =
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
>
Received on 2023-10-05 11:53:20