If you have ever written Windows code interfacing with LPCWSTR APIs and tried to serialize a number into that buffer without an extra allocation — you understand exactly why this paper exists.

// Before: the copy dance
wchar_t buf[32];
char tmp[32];
auto [end, ec] = std::to_chars(tmp, tmp + 32, value);
std::copy(tmp, end, buf); // fine-ish but annoying

// After: just works
wchar_t buf[32];
auto [end, ec] = std::to_chars(buf, buf + 32, value);

The reinterpret_cast<wchar_t*>(char_buf) version is what I see in codebases that gave up. This paper makes it unnecessary.

A non-template approach would yield an absurd overload set of 110 overloads

I love that the argument for using templates here is not "templates are elegant" but "the alternative is literally 110 function declarations that grow to 300 with <stdfloat>." Sometimes the committee gets there.

Wait, why do we have char8_t again? I thought char with UTF-8 source was already fine.

The result-type design in section 3.5 is worth slowing down on. The paper adds eight new named types — u8to_chars_result, u16to_chars_result, u32to_chars_result, wto_chars_result, and four matching from_chars variants. That looks like an API surface explosion on first read.

The steelman: you cannot make to_chars_result a class template without breaking existing code. The C++17 API is out in the wild with aggregate initialization — to_chars_result{ptr, ec} — and name-mangled into compiled object files. Making it an alias for basic_to_chars_result<char> would change the type identity in every TU that has already compiled a to_chars call. That is an ABI break with no opt-out.

The insight that makes the paper's approach actually work: to_chars_result_t<char> maps to the existing to_chars_result. Not a new type. Not a structural alias for a new type. The actual same concrete struct. This means:

1. Generic code writing auto r = std::to_chars<CharT>(buf, buf + N, value) and storing the result as to_chars_result_t<CharT> compiles cleanly for all five character types.
2. Existing code that names to_chars_result directly sees no change whatsoever.
3. You cannot accidentally mix result types from different character widths — the type system catches it.

The alias template is doing exactly what a type parameter on the original struct would have done if the C++17 designers had thought ahead. It just lives in a different place in the standard.

The verdict: this is the right call given the constraints. The lesson for future API designers: template your result types from day one, even if you ship only one instantiation. The standard is paying a naming tax here because charconv did not.

A non-template approach would yield an absurd overload set of 110 overloads

This line alone in the design section probably saved us from a very bad day at some future mailing.

All characters produced and consumed by to_chars and from_chars fall in the Basic Latin (ASCII) block.

Solid paper. My one concern: are the function template instantiations going to meaningfully add to compile times in large TUs that include <charconv>? Five character types across 22+ arithmetic types is a lot of potential instantiation surface.

Worth reading section 3.4 if you track std::format. The paper explicitly supersedes LWG4522 — which Schultke also filed — about whether std::format(wformat_string<...>) transcodes through char or calls the wchar_t overload of to_chars directly. Currently the standard wording is arguably wrong (LWG4522 is the proposed fix). Once to_chars<wchar_t> exists, you call it directly and the transcoding question goes away.

The coordination risk: if LWG adopts 4522's wording before this paper clears SG16 → LEWG → LWG, you have two conflicting wording changes targeting the same paragraph. Schultke calls this out directly in the paper, but it depends on sequencing that the committee does not always get right. Something to watch.

Looking at section 5.2 — as someone who has actually shipped C++ on z/OS with EBCDIC: yes, the _Encode<charT>(char32_t code_point) approach from the libc++ review is the right call. On EBCDIC systems, wchar_t does not encode the Basic Latin block at the same code points as Unicode. You cannot just write static_cast<wchar_t>('+') and expect it to be U+002B PLUS SIGN — it is EBCDIC 0x4E on the wire.

The paper's implementation sketch using compile-time dispatch on the character type to invoke an EBCDIC encoder is how you actually make this work portably. It is nice to see it addressed instead of footnoted.

Great paper. Now when do we get <networking> so I can actually send the numbers I just serialized somewhere?

One thing I missed in my earlier comment: the floating-point overloads have a conditional constexpr dependency on P3652R1. Integer conversion is unconditionally constexpr for all five character types (that already holds for char). But float conversion is constexpr for char only after P3652R1 ships, and the new template overloads follow the same condition.

If P3652R1 stalls, you end up with a split API: integer to_chars is constexpr across all char types, float to_chars is not constexpr for any of them. That is probably fine — it mirrors the existing state — but it means the "upgrade path" for constexpr float formatting in non-char contexts depends on two papers landing in the right order. Worth tracking if you care about compile-time number formatting.

Edit: the paper does acknowledge this dependency explicitly in section 3.6. Not a hidden issue, just easy to miss on first read.