This meeting is starting now.

Tom.

On 7/29/25 2:09 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, July 30th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250730T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/5FDDA8FA-1102-44AC-8E03-DC78F1B95BB6.ics?export>.
>
> The agenda follows.
>
> * LWG issue 4070: Transcoding by
> std::formatter<std::filesystem::path> <https://wg21.link/lwg4070>.
> * LWG issue 4090: Underspecified use of locale facets for
> locale-dependent std::format <https://wg21.link/lwg4090>.
> * P3677R0: Preserving LC_CTYPE at program start for UTF-8 locales
> <https://wg21.link/p3677r0>.
>
> Corentin has informed me that he might not be able to attend the
> meeting. In that case, we'll finish with the LWG issues and adjourn early.
>
> *LWG 4070* and *LWG 4090* were last discussed by SG16 during the
> 2024-06-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2024.md#june-12th-2024>.
> Proposed resolutions guided by the previous SG16 discussion were
> recently drafted. We'll review and poll forwarding to LWG.
>
> *LWG 4070* seeks to clarify transcoding requirements for formatting of
> std::filesystem::path and the interaction of substitution vs escaping
> for ill-formed code unit sequences. The proposed wording confirms the
> intent that escaping (when the ? format option is used) occurs first
> and that substitution happens second (with the implication that no
> substitution ever occurs when ill-formed code unit sequences are
> escaped since there is nothing left to substitute for).
>
> *LWG 4090* seeks to clarify how locale dependent formatting of numeric
> values is performed. The proposed wording specifies that the
> std::numpunct locale facet is used.
>
> *P3677R0* is simultaneously WG14 N3539
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3539.pdf> and
> proposes a change to the C standard that would affect C++.
> Specifically, it proposes that, if the locale of the program
> environment uses a UTF-8 encoding, then the program locale implicitly
> established during program startup will be the "C" locale augmented to
> use UTF-8 as the LC_CTYPE locale category. This change to the standard
> would affect the default behavior of the C standard library character
> handling functions including mblen(), mbtowc(), wctomb(), mbstowcs(),
> wcstombs(), wctype(), wctrans(), wctomb_s(), mbstowcs_s(), and
> wcstombs_s(). Python adopted a similar change via PEP 538 (Coercing
> the legacy C locale to a UTF-8 based locale)
> <https://peps.python.org/pep-0538/> for Python 3.7 back in 2017; that
> proposal is well worth reading.
>
> Tom.
>
>