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.