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
>