I won't be attending today but am generally concerned that P3395 introduces
a new transcoding that the N5001 Working Draft does not have.
The Working Draft requires transcoding from an execution encoding (the wide
one) to UTF-8.
This paper requires transcoding from an execution encoding to the ordinary
literal encoding.

The ordinary literal encoding may not even be one of the execution
encodings for any locale in the runtime environment...

This is perhaps not an issue for platforms where strings returned by
`strerror` fall within the subset of strings that are encoded the same way
across all execution encodings on the platform (and where the user uses an
ordinary literal encoding from the same "family"). I do not think that this
specific usage should be considered precedent for more general requirements
for such transcoding though.

-- HT

On Wed, Mar 12, 2025 at 1:34 PM Victor Zverovich via SG16 <
sg16_at_[hidden]> 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
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>