<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thank you, Eddie! Please send me your notes following the
      meeting. Please try to capture any polls and their results as
      well. I expect Steve will record polls and results as well, but it
      never hurts to have multiple copies to ensure there are no
      discrepancies.</p>
    <p>Victor, assuming you are able to attend, could you provide a
      brief introduction for LWG 4070 and LWG 4087?</p>
    <p>Jens, assuming you are able to attend, could you introduce LWG
      4090?</p>
    <p>Tom.<br>
    </p>
    <div class="moz-cite-prefix">On 6/12/24 12:29 PM, Eddie Nolan via
      SG16 wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHitK37sWac5a1=Y3rrDWVUcEoTWZh4j_r=BMGUq7-_aPpDcCQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I volunteer to scribe.<br>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2024 at
          12:02 PM Tom Honermann via SG16 &lt;<a
            href="mailto:sg16@lists.isocpp.org" moz-do-not-send="true"
            class="moz-txt-link-freetext">sg16@lists.isocpp.org</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <p>SG16 will hold a meeting on Wednesday, June 12th, at
              19:30 UTC (<a
href="https://www.timeanddate.com/worldclock/converter.html?iso=20240612T193000&amp;p1=1440&amp;p2=tz_pdt&amp;p3=tz_mdt&amp;p4=tz_cdt&amp;p5=tz_edt&amp;p6=tz_cest"
                target="_blank" moz-do-not-send="true">timezone
                conversion</a>).</p>
            <p>That is <b>TODAY</b>, 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.</p>
            <p>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.</p>
            <p>Since the agenda contains only LWG issues, I'm copying
              LWG in case anyone there is especially interested in these
              issues.</p>
            <p>This will be the last SG16 meeting prior to St. Louis.<br>
            </p>
            <p>The agenda follows.</p>
            <ul>
              <li><a href="https://cplusplus.github.io/LWG/issue4070"
                  target="_blank" moz-do-not-send="true">LWG issue 4070:
                  Transcoding by
                  std::formatter&lt;std::filesystem::path&gt;</a>.<br>
              </li>
              <li><a href="https://cplusplus.github.io/LWG/issue4087"
                  target="_blank" moz-do-not-send="true">LWG issue 4087:
                  Standard exception messages have unspecified encoding</a>.</li>
              <li><a href="https://cplusplus.github.io/LWG/issue4090"
                  target="_blank" moz-do-not-send="true">LWG issue 4090:
                  Underspecified use of locale facets for
                  locale-dependent std::format</a>.</li>
            </ul>
            <p>LWG 4070 concerns the wording in <a
                href="https://eel.is/c++draft/fs.path.fmtr.funcs#5"
                target="_blank" moz-do-not-send="true">[fs.path.fmtr.funcs]p5</a>
              that appears to constrain its effects to the formatting of
              escaped paths (<a
                href="https://eel.is/c++draft/format.string.escaped"
                target="_blank" moz-do-not-send="true">[format.string.escaped]</a>).
              This wording originated with <a
                href="https://wg21.link/p2845r8" target="_blank"
                moz-do-not-send="true">P2845R8 (Formatting of
                std::filesystem::path)</a> and in particular <a
                href="https://wg21.link/p2845r1" target="_blank"
                moz-do-not-send="true">P2845R1</a>; the wording in <a
                href="https://wg21.link/p2845r0" target="_blank"
                moz-do-not-send="true">P2845R0</a> 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).</p>
            <p>LWG 4087 concerns the encoding of filesystem paths in
              message returned by the <font face="monospace">what()</font>
              member of <font face="monospace">std::exception</font>.
              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 (<a
                href="https://eel.is/c++draft/multibyte.strings"
                target="_blank" moz-do-not-send="true">[multibyte.strings]</a>).
              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 <font
                face="monospace">what()</font> 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.</p>
            <p>LWG 4090 concerns <font face="monospace">std::locale</font>
              facets and which one is to be consulted when formatting
              integral (and floating-point?) types. There appear to be
              two options, 1) use <font face="monospace">std::num_put</font>
              to format the value, or 2) use <font face="monospace">std::numpunct</font>
              and require <font face="monospace">std::format</font> to
              assemble the character representation. There is no
              proposed resolution, so we'll need to determine the intent
              and provide a recommendation.<br>
            </p>
            <p>Tom.<br>
            </p>
          </div>
          -- <br>
          SG16 mailing list<br>
          <a href="mailto:SG16@lists.isocpp.org" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">SG16@lists.isocpp.org</a><br>
          <a href="https://lists.isocpp.org/mailman/listinfo.cgi/sg16"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.isocpp.org/mailman/listinfo.cgi/sg16</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
    </blockquote>
  </body>
</html>

