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.