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.