My rough notes for this meeting are available on the (✨NEW!✨) WG21 wiki
here <https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-01-14>.

The P3688 GH issue <https://github.com/cplusplus/papers/issues/2318> has
been updated to reflect the polls that were taken and is now tagged for
LEWG review.

The P3876 GH issue <https://github.com/cplusplus/papers/issues/2549> has
been updated to indicate that SG16 review has started, but has not yet
concluded.

Tom.

On 1/13/26 12:11 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, January 14th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20260114T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
>
> The agenda is:
>
> * P3688R5: ASCII character utilities <https://wg21.link/p3688r5>.
> * P3876R0: Extending <charconv> support to more character types
> <https://wg21.link/p3876r0>.
>
> Happy new year!
>
> If you concentrate hard, you might recall, way back before the
> (non-)release of the Epstein files, the friendly visits from a jolly
> man in a red suit, the celebrations of another successful
> circumnavigation of the sun, the US capture of the leader of
> Venezuela, the reignited talk of the US invading Greenland, the
> on-going ICE related tragedies in the US, and the attempts to
> politicize the Federal Reserve, a full month ago, we had been
> discussing the P3688 proposal to add a suite of ASCII related
> utilities to the standard. Jan published *P3688R5* shortly after our
> last meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-12-10>
> and, I think, has addressed all feedback that was provided. We'll
> review the new revision, ensure previously raised concerns have been
> addressed, and hopefully poll forwarding it to LEWG.
>
> *P3876R0*, for which Jan is also the primary author, seeks to
> standardize additional overloads of std::to_chars() and
> std::from_chars() (and their result types) for additional character
> types (char8_t, char16_t, char32_t, and wchar_t). As usual, we'll
> consider encoding related issues (e.g., handling for malformed code
> unit sequences) and impact on existing implementations. Fortunately,
> since these utilities are locale independent, we'll (hopefully) not
> have to wrangle with locale related concerns. This proposal is
> conceptually simple, but the paper is relatively long (in a good way),
> so I don't expect that we'll conclude discussion in this meeting.
>
> Tom.
>
>
>