The related github tracker issues for these papers have likewise been
updated with polls and a summary explanation of the SG16 consensus.

  * GH #2285 <https://github.com/cplusplus/papers/issues/2285>: P3655 R0
    zstring_view
  * GH #1529 <https://github.com/cplusplus/papers/issues/1529>: P2873 R3
    Remove Deprecated locale category facets for Unicode from C++26

Tom.

On 4/23/25 11:22 PM, Tom Honermann via SG16 wrote:
>
> Thank you to everyone that attended today.
>
> WG21 members can find the draft meeting summary with poll results at
> https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-04-23.
>
> 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.
>>
>>
>