Yes, we can do that so long as Alisdair is able to attend the latter
part of the meeting.

Tom.

On 3/12/25 1:34 PM, Victor Zverovich wrote:
> Hi Tom,
>
> I didn't realize that the meeting would be moved and so will only be
> present for the first half an hour due to a conflict. Is it possible
> to review P3395R0 first?
>
> Cheers,
> Victor
>
> On Wed, Mar 12, 2025 at 9:49 AM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> SG16 will hold a meeting *today*, Wednesday, March 12th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250312T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cet>).
>
> I apologize for the very late agenda. I had specifically set aside
> an hour to get this done at 2am on Sunday, but that hour never
> happened. Speaking of which...
>
> *For those in North America, please note that daylight savings
> time has begun, so this meeting will begin one hour later relative
> to the last meeting.*
>
> If you need a .ics file to import into your calendar, you can
> download it here
> <https://documents.isocpp.org/remote.php/dav/calendars/tahonermann/wg21-telecons_shared_by_hfinkel/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>.
>
> The agenda follows.
>
> * P2873R2: Remove Deprecated locale category facets for Unicode
> from C++26 <https://wg21.link/p2873r2>.
> * P3395R0: Formatting of std::error_code
> <https://wg21.link/p3395r0>.
>
> *P2873R0* <https://wg21.link/p2873r0> was previously reviewed by
> SG16 during the 2023-05-24
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#may-24th-2023>
> and 2023-10-25
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#october-25th-2023>
> meeting (briefly and tangentially, search for "P2873"). These
> reviews followed previous discussion of the same topic/proposal in
> the context of P2139R2 (Reviewing Deprecated Facilities of C++20
> for C++23) <https://wg21.link/p2139r2> section D.22 (Deprecated
> locale category facets [depr.locale.category]) during the
> 2020-07-22 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#july-22nd-2020>.
> There was no consensus for removal during the 2020-07-22 review,
> but there was consensus for no objection against removal (should
> LEWG decide to do so despite no SG16 recommendation to remove). No
> concerns were raised in the more recent reviews, but we never
> polled actually forwarding the paper. The later revisions have not
> altered what is proposed (beyond adding an annex C entry), but
> have significantly expanded the history, the design concerns with
> these facets, the motivation for deprecation, and the current
> implementation status with regard to the deprecation. LEWG
> reviewed P2873R2 during its 2025-03-04 meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2025/P2873#Library_Evolution_Telecon-2025-03-04>
> and approved it for inclusion in C++26/C++29 pending SG16
> agreement. We'll discuss and poll forwarding absent new concerns
> that would justify reconsideration in LEWG. LEWG's polls were
> unanimously in favor of the proposal as is.
>
> *P3395R0 <https://wg21.link/p3395r0>* comes to us courtesy of
> Victor and proposals portable formatting of std::error_code
> category names, values, and messages. For example, the following
> code might produce the annotated output.
>
> std::error_code ec((int)std::errc::no_such_file_or_directory,
> std::generic_category());
> std::print("{}\n", ec); // prints "generic:2"
> std::print("{:s}\n", ec); // prints "No such file or directory"
>
> Of course, there wouldn't be much to talk about in SG16 if there
> weren't complications. The encoding of the strings returned by
> std::error_category::name() ([syserr.errcat.virtuals]p1
> <https://eel.is/c++draft/syserr#errcat.virtuals-1>) and
> std::error_category::message() ([syserr.errcat.virtuals]p5
> <https://eel.is/c++draft/syserr#errcat.virtuals-5>) are not well
> specified in the standard. The proposal acknowledges this,
> suggests clarifications, and proposes that the new std::error_code
> formatter perform necessary transcoding. See also LWG 4156
> (error_category messages have unspecified encoding)
> <https://cplusplus.github.io/LWG/issue4156>. The concerns are
> similar to those we previously discussed for LWG 4087 (Standard
> exception messages have unspecified encoding)
> <https://cplusplus.github.io/LWG/issue4087>.
>
> Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>