This is your friendly reminder that this meeting is taking place tomorrow.

Tom.

On 5/22/23 1:33 PM, Tom Honermann via SG16 wrote:
>
> 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.
>
>
>