This meeting is starting now.

Tom.

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