On 12/06/2024 19.17, Tom Honermann via SG16 wrote:
> Jens, assuming you are able to attend, could you introduce LWG 4090?

Yes.

Jens




> Tom.
>
> On 6/12/24 12:29 PM, Eddie Nolan via SG16 wrote:
>> I volunteer to scribe.
>>
>> On Wed, Jun 12, 2024 at 12:02 PM Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
>>
>> SG16 will hold a meeting on Wednesday, June 12th, at 19:30 UTC (timezone conversion <https://www.timeanddate.com/worldclock/converter.html?iso=20240612T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>>
>> That is *TODAY*, in about 3 1/2 hours. I apologize for the late agenda; work demands, the kids being out of school, and summer activities have me even further behind than usual.
>>
>> Steve will be chairing the meeting today and I will not be able to scribe; someone please volunteer to do so. I will try to attend, but will have to do so from my car while transporting my kids.
>>
>> Since the agenda contains only LWG issues, I'm copying LWG in case anyone there is especially interested in these issues.
>>
>> This will be the last SG16 meeting prior to St. Louis.
>>
>> The agenda follows.
>>
>> * LWG issue 4070: Transcoding by std::formatter<std::filesystem::path> <https://cplusplus.github.io/LWG/issue4070>.
>> * LWG issue 4087: Standard exception messages have unspecified encoding <https://cplusplus.github.io/LWG/issue4087>.
>> * LWG issue 4090: Underspecified use of locale facets for locale-dependent std::format <https://cplusplus.github.io/LWG/issue4090>.
>>
>> LWG 4070 concerns the wording in [fs.path.fmtr.funcs]p5 <https://eel.is/c++draft/fs.path.fmtr.funcs#5> that appears to constrain its effects to the formatting of escaped paths ([format.string.escaped] <https://eel.is/c++draft/format.string.escaped>). This wording originated with P2845R8 (Formatting of std::filesystem::path) <https://wg21.link/p2845r8> and in particular P2845R1 <https://wg21.link/p2845r1>; the wording in P2845R0 <https://wg21.link/p2845r0> does not have the "escaped path" constraint. We'll need to determine what the intended behavior is and then provide a recommendation on wording updates. The LWG issue includes a proposed resolution (PR). With respect to the PR, I think the proposed update to implementation-defined behavior is subtly incorrect; the implementation-defined behavior comes into play when the ordinary literal encoding is not UTF-8 (an implementation may still convert to UTF-8 when the ordinary literal encoding is not UTF-8).
>>
>> LWG 4087 concerns the encoding of filesystem paths in message returned by the what() member of std::exception. At present, mojibake is produced when the contents of a path don't produce a well-formed sequence of code units in the encoding of a multibyte string ([multibyte.strings] <https://eel.is/c++draft/multibyte.strings>). The LWG issue includes a PR, but I don't think it is implementable, at least not as currently worded. The wording attempts to restrict all messages returned by what() to the ordinary literal encoding, but implementations may return localized messages (in a locale dependent encoding) today. We'll need to discuss alternative solutions and provide a recommendation.
>>
>> LWG 4090 concerns std::locale facets and which one is to be consulted when formatting integral (and floating-point?) types. There appear to be two options, 1) use std::num_put to format the value, or 2) use std::numpunct and require std::format to assemble the character representation. There is no proposed resolution, so we'll need to determine the intent and provide a recommendation.
>>
>> Tom.
>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>>
>