Thanks, Tom. Glad to see all the 🤣 in the Zoom chat were captured.

- Victor

On Thu, Sep 11, 2025 at 4:18 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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 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)
> <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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2025/09/4612.php
>