SG16 will hold a meeting tomorrow, Wednesday, August 27th, 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 4090: Underspecified use of locale facets for locale-dependent std::format.
• P3681R0: char_traits: Stop the bleeding!
  

We last discussed LWG issue 4090 during the 2025-07-30 SG16 meeting (previous discussion was during the 2024-06-12 SG16 meeting). 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) to address LWG issue 3565. 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. 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 characters as 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 characters as 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). SG16 discussed P3655R0 during the 2025-04-23 SG16 meeting 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.