SG16 will hold a telecon on Wednesday, May 24th, at 19:30 UTC (timezone
conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20230524T193000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_ct&p5=tz_et&p6=tz_cest>).

The agenda follows.

  * P2779R0: Make basic_string_view’s range construction conditionally
    explicit <https://wg21.link/p2779r0>.
  * P2863R0: Review Annex D for C++26 <https://wg21.link/p2863r0>.
  * P2871R0: Remove Deprecated Unicode Conversion Facets From C++26
    <https://wg21.link/p2871r0>.
  * P2872R0: Remove wstring_convert From C++26 <https://wg21.link/p2872r0>.
  * P2873R0: Remove Deprecated Locale Category Facets For Unicode from
    C++26 <https://wg21.link/p2873r0>.

P2779R0 was briefly discussed during the 2023-04-26 SG16 telecon
<https://github.com/sg16-unicode/sg16-meetings#april-26th-2023>. This
time around, the author is expected to be present so we'll have an
opportunity to hear his perspective. The primary SG16 concern is the
proposed same-type match of a member traits_type type alias to determine
whether a type is implicitly convertible to a std::string_view
specialization. There is a bit of history here. The proposed wording is
relative to the C++ Working Draft as specified in N4928
<https://wg21.link/n4928>, but that is no longer the status quo. The
proposed removal of [string.view.cons]p12
<http://eel.is/c++draft/string.view.cons#12> sub paragraph 6 (12.6)
already occurred via LWG 3857 <https://wg21.link/lwg3857>. The proposal
actually resurrects that wording (in both proposed options) and
repurposes it for the proposed conditionally explicit behavior. Both
proposed options require matching traits_type type aliases to enable
implicit conversions; the difference is that option 1 also requires a
std::is_string_view_like variable template specialization to be true in
order to enable implicit conversions. When last discussed, Victor
asserted that the maintainers of Folly's basic_fbstring
<https://github.com/facebook/folly/blob/main/folly/FBString.h#L962>
alternative to std::string would not want such implicit conversions
enabled. I'd like to better understand why that is. Our goal will be to
poll forwarding the paper with a preference for option 1 or option2.

The remaining papers are all courtesy of Alisdair and address the
removal of previously deprecated features. For P2863R0, the only item of
discussion is that std::filesystem::u8path is not proposed for removal;
see section 6.29 for rationale. P2871R0 proposes the removal of
std::codecvt_utf16, std::codecvt_utf8, and std::codecvt_utf8_utf16, all
of which were deprecated in C++17. P2872R0 proposes the removal of
std::wstring_convert which was deprecated in C++17. Finally, P2873R0
proposes removal of the std::codecvt<char16_t, char, mbstate_t>,
std::codecvt<char32_t, char, mbstate_t>, std::codecvt_byname<char16_t,
char, mbstate_t>, and std::codecvt_byname<char32_t, char, mbstate_t>
specializations, all of which were deprecated in C++20. With regard to
this last paper, we may want to consider LWG 3767
<https://wg21.link/lwg3767> as well and the mistake that was made (by
me) in adding the std::codecvt<char16_t, char8_t, mbstate_t>,
std::codecvt<char32_t, char8_t, mbstate_t>,
std::codecvt_byname<char16_t, char8_t, mbstate_t>, and
std::codecvt_byname<char32_t, char8_t, mbstate_t> specializations.

If we don't get through all of these papers in this meeting, then we'll
plan to meet again either May 31st or June 7th to finish reviews in time
for the Varna meeting.

Tom.