Discussion:
[std-proposals] to_string customisation function
n***@gmail.com
2018-10-10 12:21:54 UTC
Permalink
Currently std::to_string can be used as a customization point by the
following:

using std::to_string
std::string a = to_string(some_object);

However, using "using" every time is tedious. We can add a wrapper to that:

#include<iostream>

template< typename T>
std::string as_string(T &&o) {
using std::to_string;
returnto_string(std::forward<T>(o));
}

classA {};

std::string to_string(constA &a) {
return"hello";
}

intmain() {
std::cout << as_string(1) << as_string(A{});
return0;
}

Doing that in each project is just a boilerplate. Is there any proposal to
standardize something like that? It does not require any language feature,
but would be nice to have as a part of a standard library. It can be used
if we want to add some sort of possibility to add to_string conversion to
things like enums or any other built-in construct.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e3b84ef-15c8-42d4-a5de-5ce9ee3c078c%40isocpp.org.
Jake Arkinstall
2018-10-10 12:36:15 UTC
Permalink
You don't have to use using std::to_string every time. You can put it in a
global scope, and as long as it is seen before the first usage it isn't an
issue.

I have no wish to have std functions in the global namespace, so I use the
full std::to_string on the rare occasions that I have a use for it. There
will also be conflicts with projects that already have some as_string
function, so standardising it in the global namespace would break their
code.
Post by n***@gmail.com
Currently std::to_string can be used as a customization point by the
using std::to_string
std::string a = to_string(some_object);
#include<iostream>
template< typename T>
std::string as_string(T &&o) {
using std::to_string;
returnto_string(std::forward<T>(o));
}
classA {};
std::string to_string(constA &a) {
return"hello";
}
intmain() {
std::cout << as_string(1) << as_string(A{});
return0;
}
Doing that in each project is just a boilerplate. Is there any proposal to
standardize something like that? It does not require any language feature,
but would be nice to have as a part of a standard library. It can be used
if we want to add some sort of possibility to add to_string conversion to
things like enums or any other built-in construct.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e3b84ef-15c8-42d4-a5de-5ce9ee3c078c%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e3b84ef-15c8-42d4-a5de-5ce9ee3c078c%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOrKHuuAZY%2B%2BzAi6WF4a9VsmFZCB9LwB0e5qnwfAJRz%3DQ%40mail.gmail.com.
Nikita Alekseev
2018-10-10 12:41:05 UTC
Permalink
The issue of using std::to_string as a full name creates an issue when I
want to do it with a custom type. I would have to use a separate function
for that. This might be an issue in generic code, where I am forced to have
using std::to_string each time I want to do that.

As for the issue with conflicts, if it is standardized, as_string will be a
part of std namespace, the only way it can conflict with some existing
function is if it was an unqualified call. This is an issue for any
function which can be added to the standard library.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae38a92d-b554-4219-9cd6-5a5248512c1e%40isocpp.org.
Nicolas Lesser
2018-10-10 12:52:46 UTC
Permalink
std::to_string is not a customization point, as such, it doesn't make sense
to provide such a function. You'll have to propose making a customization
point for it first :)
Post by Nikita Alekseev
The issue of using std::to_string as a full name creates an issue when I
want to do it with a custom type. I would have to use a separate function
for that. This might be an issue in generic code, where I am forced to have
using std::to_string each time I want to do that.
As for the issue with conflicts, if it is standardized, as_string will be
a part of std namespace, the only way it can conflict with some existing
function is if it was an unqualified call. This is an issue for any
function which can be added to the standard library.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae38a92d-b554-4219-9cd6-5a5248512c1e%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae38a92d-b554-4219-9cd6-5a5248512c1e%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq02QSkcrAC0MMFYm%2B0wTxrj%3D9c6THJ5H8DMte%2BPAD8oVA%40mail.gmail.com.
Nikita Alekseev
2018-10-10 12:59:19 UTC
Permalink
Is it a feasible proposal to make to_string a customization point? As I
understand It is not a fundamental operation, such as swap or begin/end,
but it is widely applicable in real-world code and I do not see any
negative impact it might have. Other languages seem to provide such
customization point like that (toString() from Java as an example),
however, I do not know the technical aspects of that, what is the process
of making something a customization point? What work needs to be done to do
that?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7df1e323-eab7-43f6-86a2-eaf44caf65bb%40isocpp.org.
Jake Arkinstall
2018-10-10 13:12:37 UTC
Permalink
I see what you mean.

Having it inside of the standard namespace would prevent any method it uses
from being customisable by tradition. I guess it is possible to have it
allowed, but it doesn't make a whole lot of sense to me. An easier
alternative is just add a templated overload to to_string that checks for a
"operator std::to_string()" method, and just calls that. No changes to the
"don't mess with the std namespace in user code" philosophy required.

One important thing to note: whereas numeric values have a popular
language-independent, debug-level-independent, context-independent string
representation, the same can rarely be said for general types. Even when we
think we have something in the format we want it in, requirements change.
Because of that, using suitable libraries to generate human readable output
is always going to be better than a single function that converts objects
in a single manner.

On 10 Oct 2018 13:41, "Nikita Alekseev" <***@gmail.com> wrote:

The issue of using std::to_string as a full name creates an issue when I
want to do it with a custom type. I would have to use a separate function
for that. This might be an issue in generic code, where I am forced to have
using std::to_string each time I want to do that.

As for the issue with conflicts, if it is standardized, as_string will be a
part of std namespace, the only way it can conflict with some existing
function is if it was an unqualified call. This is an issue for any
function which can be added to the standard library.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae38a92d-b554-4219-9cd6-5a5248512c1e%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae38a92d-b554-4219-9cd6-5a5248512c1e%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMP-LQpchMnWnHDsDCdXFRyFTk0BwdOL5hySWreSaPm8w%40mail.gmail.com.
Loading...