My rough notes for this meeting are available on the WG21 wiki here
<https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-08-27>.
The LWG 4090 GH issue <https://github.com/cplusplus/papers/issues/1893>
has been updated. I'm still waiting for a new proposed resolution to be
posted to LWG 4090 <https://cplusplus.github.io/LWG/issue4090> before
removing the SG16 label.

Tom.

On 8/26/25 5:35 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, August 27th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250827T193000&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 4090: Underspecified use of locale facets for
> locale-dependent std::format <https://wg21.link/lwg4090>.
> * P3681R0: char_traits: Stop the bleeding! <https://wg21.link/p3681r0>
>
> We last discussed *LWG issue 4090* during the 2025-07-30 SG16 meeting
> (previous discussion was during the 2024-06-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2024.md#june-12th-2024>).
> We concluded the last meeting with some homework for Victor to improve
> the proposed resolution wording provided by Jonathan to incorporate
> encoding related wording similar to that added by P2419R2 (Clarify
> handling of encodings in localized formatting of chrono types)
> <https://wg21.link/p2419r2> to address LWG issue 3565
> <https://wg21.link/lwg3565>. Victor did so and provided the following
> suggested wording (in an email that I just realized was only sent to
> me; I thought it had gone to the SG16 mailing list) as a change to
> [format.string.std]p17 <https://eel.is/c++draft/format.string.std#17>.
> This adds the last sentence; the rest matches Jonathan's proposed wording.
>
> When the L option is used, the form used for the conversion is
> called the /locale-specific form/. The L option is only valid for
> arithmetic types, and its effect depends upon the type.
>
> * For integral types, the locale-specific form causes the
> context's locale to be used to insert the appropriate digit
> group separator charactersas if obtained with
> numpunct<charT>::grouping and numpunct<charT>::thousands_sep.
> * For floating-point types, the locale-specific form causes the
> context's locale to be used to insert the appropriate digit
> group and radix separator charactersas if obtained with
> numpunct<charT>::grouping, numpunct<charT>::thousands_sep, and
> numpunct<charT>::decimal_point.
> * For the textual representation of bool, the locale-specific
> form causes the context's locale to be used to insert the
> appropriate string as if obtained with
> numpunct​<charT>::​truename or numpunct<charT>​::​falsename.
>
> If the string literal encoding is a Unicode encoding form and the
> locale is among an implementation-defined set of locales, each
> replacement that depends on the locale is performed as if the
> replacement character sequence is converted to the string literal
> encoding.
>
> *P3681R0* is Corentin's attempt to dissuade the continued appearance
> of std::char_traits in new standard library features and comes to us
> following discussions of P3655 (std::zstring_view)
> <https://wg21.link/p3655>. SG16 discussed P3655R0 during the
> 2025-04-23 SG16 meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-04-23>
> where we took the following poll.
>
> *Poll 1: P3655R0: No objection to use of std::char_traits for
> consistency and compatibility with std::string_view.*
>
> * Attendees: 8 (no abstentions)
> *
> SF
> F
> N
> A
> SA
> 7
> 1
> 0
> 0
> 0
>
> * Strong consensus.
>
> Corentin was not present for that meeting, so this paper does not
> represent a change of opinion from him, but rather a request to
> reconsider that poll and to perhaps establish a policy related to
> std::char_traits for future work. The paper explicitly addresses the
> possibility of custom char trait types and how such existing use with
> std::basic_string would impact convertibility to std::zstring_view.
>
> Tom.
>
>