This meeting is starting in ~5 minutes.

Tom.

On 4/22/25 3:19 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, April 23rd, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250409T193000&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.
>
> * P3655R0: std::zstring_view <https://wg21.link/p3655r0>.
> * P2873R3: Remove Deprecated locale category facets for Unicode from
> C++26 <https://wg21.link/p2873r3>.
>
> *P3655R0* seeks to standardize a variant of std::string_view that
> offers a null termination guarantee. This is not the first paper to
> propose such a type; nor the second, nor the third! Given the history
> of papers (see section 3 in the paper) that stalled for one reason or
> another, the motivation for SG16 review is to provide a (hopefully
> strong) recommendation to LEWG (one way or the other) regarding the
> utility of the proposed type from a group of text experts. This
> proposal was on the agenda for the last SG16 meeting, but was not
> discussed. There was some mailing list discussion
> <https://lists.isocpp.org/sg16/2025/04/4545.php> that I urge
> participants to read before the meeting tomorrow. That discussion
> concerned:
>
> * Support for std::char_traits.
> * Support for conversion to std::string_view and implications for
> invariants, creation of temporaries, and life-time concerns.
>
> *P2873R3*, well, a draft of it, was already forwarded by SG16 during
> the 2025-03-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings#march-12th-2025>. The
> only reason that it is back on the agenda again is to provide a
> recommendation whether all of the deprecated std::codecvt facets
> should be removed in C++26 or whether the ones that were deprecated
> during C++26 should be retained for removal in a future standard.
> There was a small amount of mailing list discussion
> <https://lists.isocpp.org/sg16/2025/03/4541.php> regarding this last
> month. The status quo is:
>
> * Introduced in C++11 (via N2238 <https://wg21.link/n2238>),
> deprecated in C++20 (via P0482R6 <https://wg21.link/p0482r6>), on
> track to be removed in C++26 (via P2873R3
> <https://wg21.link/p2873r3>):
> o codecvt<char16_t, char, mbstate_t>
> o codecvt<char32_t, char, mbstate_t>
> o codecvt_byname<char16_t, char, mbstate_t>
> o codecvt_byname<char32_t, char, mbstate_t>
> * Introduced in C++20 (via P0482R6 <https://wg21.link/p0482r6>),
> deprecated in C++26 (via LWG 3767 <https://wg21.link/lwg3767>),
> should be removed in C++26?
> o codecvt<char16_t, char8_t, mbstate_t>
> o codecvt<char32_t, char8_t, mbstate_t>
> o codecvt_byname<char16_t, char8_t, mbstate_t>
> o codecvt_byname<char32_t, char8_t, mbstate_t>
>
> Note that the latter set that convert to/from char8_t should not have
> been added to the standard in the first place. UTF conversions are
> never locale dependent, nor is support for file streams of char8_t (or
> char16_t or char32_t) required by the standard. Nothing in the C++
> standard library depends on these facets. Removal of these facets does
> remove the only UTF transcoding facility currently specified by the
> C++ standard, but such conversions are still possible using facilities
> from C (e.g., c8rtomb() followed by mbrtoc16(), at least for
> characters in the BMP).
>
> Tom.
>
>