P2587R3 Redefining `to_string` To Use `to_chars`

[StephanTLavavej]

WG21-P2587R3 Redefining to_string To Use to_chars

Feature-test macro:

#define __cpp_lib_to_string 202306L

Note: We are not yet accepting PRs for C++26 features.

[owacoder]

I'd be interested in working on this.

[StephanTLavavej]

Sure, I've moved this to Investigating for you. (As I've mentioned elsewhere, I do plan to open up the repo to C++26 PRs soon, although ideally we should land feature/flat_map first.)

[owacoder]

Since using format as described by the paper is really unnecessary, and only a dependency on to_chars is needed, is it possible to just include <charconv> instead of <format>? Otherwise, there will be a circular dependency where format needs string and string needs format.

As the original author of this answer I would also like to include/relicense/contribute my code into the implementation to allocate appropriately ahead of time (documenting here so there's no licensing issues).

For wide chars, either a conversion will be needed or a dependency on format. I realize the conversion can be a simple widening of each character since the set of characters is limited and well-defined, but don't know which approach is preferable. Would you be able to advise?

[frederick-vs-ja]

Since using format as described by the paper is really unnecessary, and only a dependency on to_chars is needed, is it possible to just include <charconv> instead of <format>?

Yes.

Otherwise, there will be a circular dependency where format needs string and string needs format.

Even if we use std::format in std::to_string as indicated by the standard wording, the circular dependency can be avoided by splitting headers, because we don't use std::to_string in <format>.

For wide chars, either a conversion will be needed or a dependency on format. I realize the conversion can be a simple widening of each character since the set of characters is limited and well-defined, but don't know which approach is preferable. Would you be able to advise?

I think the latter is preferable. Actually, in <format> we're already performing such simple widening.

[owacoder]

It seems a severe pessimization to call out to format("{}", _Val) instead of just calling to_chars directly.

1. The parsing overhead for the format string would be completely unnecessary.
2. If to_string requires <format>, and to_string must be defined in <string>, that means the overhead for pulling in <format> is now relevant for any <string> inclusion. Using to_chars only requires pulling in <charconv>.

Is it permissible to call to_chars under an "as-if" rule since it has the same behavior? Given the title of the revision paper (and the simplicity of the underlying implementation) it would appear to me that's acceptable.

[StephanTLavavej]

Yes, I believe it is permissible to call to_chars via "as if". It's because there's no way for users to affect how format calls to_chars here.

[owacoder]

This is now implemented here: https://github.com/owacoder/STL/tree/p2587r3.

However, the new implementation requires that <string> pull in <charconv>. I don't know the STL procedures well enough to know if that is okay or if more code needs to be extracted out.

I also have not added test coverage yet.

[frederick-vs-ja]

I think we can include <charconv> in <string> only since C++26. Perhaps we can split the to_chars part improve throughput. Also, it seem that some stuffs should be inlined as it's used only once.

[AlexDeFoc]

any updates? the repo doesn't show anymore commits since a year ago

[owacoder]

Just waiting for C++26 floodgates to open. It just needs test coverage, otherwise it should be ready to go.