to_string customisation function

[n.aleks...@gmail.com]

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.

[Jake Arkinstall]

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.

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@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.

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

[Nicolas Lesser]

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

On Wed, Oct 10, 2018 at 2:41 PM Nikita Alekseev <n.aleks...@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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@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.

[Nikita Alekseev]

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?

[Jake Arkinstall]

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" <n.aleks...@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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@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.