this is happening now

On Wed, Sep 11, 2024 at 12:27 AM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> This is your friendly reminder that this meeting is taking place tomorrow.
>
> Tom.
> On 9/9/24 12:56 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting on Wednesday, September 11th, at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240911T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>
> ).
>
> The agenda follows.
>
> - P2319R0: Prevent path presentation problems
> <https://wg21.link/p2319r0>.
> - P2019R6: Thread attributes <https://wg21.link/p2019r6>.
> - P3364R0: Remove Deprecated u8path overloads From C++26
> <https://wg21.link/p3364r0>.
>
> P2319R0 is a new paper courtesy of Victor that seeks to resolve some
> ambiguous encoding issues with std::filesystem::path. It proposes to
> deprecate and replace the existing string() member function with new
> display_string() and system_string() member functions with clear encoding
> specifications. Similar replacements are proposed for the existing
> generic_string() member function. Note that these ambiguous encoding
> issues are not present for the u8, u16, and u32 prefixed variants of
> these functions; we can discuss whether similar concerns are present for
> wstring() and generic_wstring(). We'll review the paper and potentially
> poll forwarding it.
>
> P2019R6 has been around for a while but has not previously been reviewed
> by SG16. The only concern for SG16 to weigh in on is the handling of thread
> names. See the "Threads have a name" and "Constraints" sections for
> background information and the proposed wording for the thread::name_hint
> class. As proposed, thread names may be specified via
> std::basic_string_view<char> or std::basic_string_view<char8_t>; fully
> portable code will therefore be constrained to characters from the *basic
> literal character set*. No requirements for handling of transcoding
> issues or ill-formed encoded names are specified.
>
> P3364R0 has not been previously reviewed by SG16, but it split from P2863R0
> (Review Annex D for C++26) <https://wg21.link/p2863r0> which we did
> review during the 2023-05-24 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#may-24th-2023>.
> LWG 3840 <https://wg21.link/lwg3840> was previously filed to undeprecate
> std::filesystem::u8path(). SG16 did not review the LWG issue; LEWG found
> no consensus for it during the 2023-01-10 LEWG meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2023/LWG3840>. A poll in SG16
> for P2139R2 (Reviewing Deprecated Facilities of C++20 for C++23)
> <https://wg21.link/p2139r2> during the 2020-07-22 SG16 meeting
> <https://wg21.link/p2139r2> had consensus for removal of
> std::filesystem::u8path; see the discussion of D.23 (Deprecated
> filesystem path factory functions [depr.fs.path.factory]). The poll taken
> then is copied below.
>
> - *Poll: Does SG16 object to removal of the deprecated filesystem path
> factory functions in D.23 [depr.fs.path.factory]?*
> -
>
> Attendees: 9
> Yes No
> 0 9
> -
>
> Consensus is no objection.
>
> Since this poll was taken four years ago, it makes sense to re-poll it for
> the new paper. We'll discuss any new information anyone has to offer and
> likely poll effectively the same question.
>
> Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>