SG16 will hold a meeting tomorrow, Wednesday, July 30th, at 19:30 UTC (timezone conversion).

If you need a .ics file to import into your calendar, you can download it here.

The agenda follows.

• LWG issue 4070: Transcoding by std::formatter<std::filesystem::path>.
• LWG issue 4090: Underspecified use of locale facets for locale-dependent std::format.
• P3677R0: Preserving LC_CTYPE at program start for UTF-8 locales.

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. 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 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) for Python 3.7 back in 2017; that proposal is well worth reading.

Tom.