This meeting is starting in 5 minutes.

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).

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

The agenda follows.

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.

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.

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.