<!doctype html public "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

<head>
<title>SG16: Unicode meeting summaries 2021-04-14 through 2021-05-26</title>
</head>

<style type="text/css">

table#header th,
table#header td
{
    text-align: left;
}

tt {
    font-family: monospace;
}

/* Thanks to Elias Kosunen for the following CSS suggestions! */

* {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
    line-height: 125%;
}

html, body {
    background-color: #eee;
}

h1, h2, h3, h4, h5, p, span, li, dt, dd {
    color: #333;
}

p, li {
    line-height: 140%;
}

body {
    padding: 1em;
    max-width: 1600px;
}

p, li {
    -moz-osx-font-smoothing: grayscale;
    -webkit-font-smoothing: antialiased !important;
    -moz-font-smoothing: antialiased !important;
    text-rendering: optimizelegibility !important;
    letter-spacing: .01em;
}

h1, h2, h3 {
    margin-bottom: 1em;
    letter-spacing: .03em;
}

blockquote.quote
{
    margin-left: 0em;
    border-style: solid;
    background-color: lemonchiffon;
    color: #000000;
    border: 1px solid black;
}

</style>

<body>

<table id="header">
  <tr>
    <th>Document Number:</th>
    <td>P2397R0</td>
  </tr>
  <tr>
    <th>Date:</th>
    <td>2021-06-15</td>
  </tr>
  <tr>
    <th>Audience:</th>
    <td>SG16</td>
  </tr>
  <tr>
    <th>Reply-to:</th>
    <td>Tom Honermann &lt;tom@honermann.net&gt;</td>
  </tr>
</table>


<h1>SG16: Unicode meeting summaries 2021-04-14 through 2021-05-26</h1>

<p>
Summaries of SG16 meetings are maintained at
<a href="https://github.com/sg16-unicode/sg16-meetings">
https://github.com/sg16-unicode/sg16-meetings</a>.  This paper contains a
snapshot of select meeting summaries from that repository.
</p>

<ul>
  <li><a href="#2021_04_14">
      April 14th, 2021</a></li>
  <li><a href="#2021_04_28">
      April 28th, 2021</a></li>
  <li><a href="#2021_05_12">
      May 12th, 2021</a></li>
  <li><a href="#2021_05_26">
      May 26th, 2021</a></li>
</ul>

<p>
Previously published SG16 meeting summary papers:
<ul>
  <li><a href="https://wg21.link/p1080">P1080: SG16: Unicode meeting summaries 2018/03/28 - 2018/04/25</a></li>
  <li><a href="https://wg21.link/p1137">P1137: SG16: Unicode meeting summaries 2018/05/16 - 2018/06/20</a></li>
  <li><a href="https://wg21.link/p1237">P1237: SG16: Unicode meeting summaries 2018/07/11 - 2018/10/03</a></li>
  <li><a href="https://wg21.link/p1422">P1422: SG16: Unicode meeting summaries 2018/10/17 - 2019/01/09</a></li>
  <li><a href="https://wg21.link/p1666">P1666: SG16: Unicode meeting summaries 2019/01/23 - 2019/05/22</a></li>
  <li><a href="https://wg21.link/p1896">P1896: SG16: Unicode meeting summaries 2019/06/12 - 2019/09/25</a></li>
  <li><a href="https://wg21.link/p2009">P2009: SG16: Unicode meeting summaries 2019-10-09 through 2019-12-11</a></li>
  <li><a href="https://wg21.link/p2179">P2179: SG16: Unicode meeting summaries 2020-01-08 through 2020-05-27</a></li>
  <li><a href="https://wg21.link/p2217">P2217: SG16: Unicode meeting summaries 2020-06-10 through 2020-08-26</a></li>
  <li><a href="https://wg21.link/p2253">P2253: SG16: Unicode meeting summaries 2020-09-09 through 2020-11-11</a></li>
  <li><a href="https://wg21.link/p2352">P2352: SG16: Unicode meeting summaries 2020-12-09 through 2021-03-24</a></li>
</ul>
</p>


<h1 id="2021_04_14">April 14th, 2021</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://isocpp.org/files/papers/P2295R2.pdf">P2295R2: Correct UTF-8 handling during phase 1 of translation</a></li>
  <li><a href="https://isocpp.org/files/papers/P2348R0.pdf">P2348R0: Whitespaces Wording Revamp</a></li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Corentin Jabot</li>
  <li>Hubert Tong</li>
  <li>JeanHeyd Meneide</li>
  <li>Jens Maurer</li>
  <li>Mark Zeren</li>
  <li>Peter Bindels</li>
  <li>Peter Brett</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>PBrett introduced the agenda.</li>
  <li><a href="https://isocpp.org/files/papers/P2295R2.pdf">P2295R2: Correct UTF-8 handling during phase 1 of translation</a>
    <ul>
      <li>Corentin introduced:
        <ul>
          <li>This is a proposal to require that UTF-8 be one of the set of
              otherwise implementation-defined source file encodings.</li>
          <li>With regard to ill-formed code unit sequences, there is no such
              thing; the source code is either valid UTF-8 or it is not
              UTF-8.</li>
          <li>Gcc does not validate its presumed UTF-8 input.</li>
          <li>With regard to BOMs, the proposal does not impose any
              requirements other than that a BOM present in a UTF-8 source
              file be ignored for the purposes of lexing.</li>
          <li>An implementation may use the presence or non-presence of a BOM
              as part of its source file encoding determination.</li>
          <li>The proposed wording will require updates for changes that will
              presumably be adopted from Jens'
              <a href="https://wg21.link/p2314">P2314: Character sets and encodings</a>.</li>
          <li>This proposal follows Beman Dawes' earlier proposal,
              <a href="https://wg21.link/n3463">N3463: Portable Program Source Files</a>.</li>
          <li>At present, the C++ standard has no requirement for a portable
              source file.</li>
        </ul>
      </li>
      <li>Tom stated that gcc will perform UTF-8 validation if both
          <tt>-finput-charset=utf-8</tt> and <tt>-fexec-charset=utf-8</tt>
          are specified.</li>
      <li><em>[ Editor's note: Tom was wrong (and since Tom is also the editor,
          he can be blunt like that); gcc only validates UTF-8 for string
          literals, and then only if <tt>-fexec-charset=&lt;encoding&gt;</tt>
          is specified. ]</em></li>
      <li>Jens noted a capitalization issue in the wording; the sentence
          following the added note in [lex.phases]p1 has a capitalized "The"
          following a ";".</li>
      <li>Jens asked why the note added to [lex.phases]p1 is just a note; the
          preceding prose provides a definition, but does not impose any
          requirements.</li>
      <li>PBrett responded that, if an invalid sequence is present, then there
          is no sequence of Unicode scalar values.</li>
      <li>PBrett asked if moving the note after the following sentence would
          resolve the concern.</li>
      <li>Jens replied that it would not; that would define a UTF-8 source file
          and state that a well-formed UTF-8 source file must be accepted, but
          would impose no requirements on an ill-formed UTF-8 source file.</li>
      <li>PBrett acknowledged that further wording work is needed.</li>
      <li>Jens observed, and noted that the paper discusses, that
          implementations can accept source files that approximate UTF-8.</li>
      <li>Hubert noted that a normative statement is needed to state that it is
          implementation-defined how a requirement for UTF-8 source files is
          specified.</li>
      <li>PBindels suggested placing a requirement for well-formed input with
          the character set definitions.</li>
      <li>Jens indicated no objection to clarification, but that he would like
          to see the ISO 10646 definition of "well-formed".</li>
      <li>Steve observed that the note is stating that invalid UTF-8 sequences
          cannot happen in a well-formed UTF-8 source file.</li>
      <li>Jens responded that there is a normative difference between
          something that cannot happen and something that is ill-formed; the
          latter requires a diagnostic.</li>
      <li>Hubert asserted that the wording needs to establish intent; a
          sequence of bytes may happen to be well-formed UTF-8, but the
          wording needs to ensure that the bytes were intended to be
          interpreted as UTF-8.</li>
      <li>PBindels summarized; we need to state there is an
          implementation-defined way to specify that a source file is to be
          interpreted as UTF-8.</li>
      <li>Jens agreed.</li>
      <li>JenaHeyd agreed from chat, "Yes, Hubert's definition is correct. You
          have to make it so the implementation has a way to mark/identify a
          source file as UTF-8, and then you can impose these requirements."</li>
      <li>Corentin stated the intent; that the compiler determine the source
          encoding in an implementation-defined way, but that a source file
          that does not decode successfully is diagnosed as ill-formed.</li>
      <li>Tom suggested specifying that the file must decode successfully as
          opposed to being well-formed.</li>
      <li>PBrett stated that a branch is needed in translation phase 1 to
          distinguish the cases where the source file is encoded as UTF-8 vs
          some other encoding.</li>
      <li>Zach suggested that a definition for a UTF-8 source file is
          unnecessary.</li>
      <li>PBindels expressed concern that there may be a conflict between use
          of a BOM and a truly portable source file.</li>
      <li>PBrett responded that the goal is that, if a source file is UTF-8
          encoded, that there is a way to direct an implementation to process
          it as such.</li>
      <li>Jens acknowledged and added that an implementation could require use
          of a command line option to opt-in to UTF-8 encoded source files;
          that implies that the source file is not automatically portable,
          but is the best we can do.</li>
      <li>Tom agreed and stated that the only way we could do better is to
          require a BOM everywhere and nobody wants that.</li>
      <li>Zach noted that the only statement made regarding a BOM is that it
          can be ignored; presumably after encoding determination is complete
          so that the BOM doesn't interfere with translation phase 2.</li>
      <li>Hubert noted that, once the encoding is determined to be UTF-8, a
          BOM is portably ignored.</li>
      <li>PBrett encouraged assumption of non-hostile implementations; no
          implementation is going to require a BOM in order for a UTF-8
          encoded source file to be processed as such.</li>
      <li>Several relevant comments were made from chat:
        <ul>
          <li>Steve: "We want portable source code. If anyone requires a BOM,
              then portable source code needs one."</li>
          <li>JeanHeyd: "If you put in a BOM and use -fexec-charset=SHIFT-JIS,
              the implementation can ignore the BOM and still read everything
              as SHIFT-JIS."</li>
          <li>Hubert: "If you did that, the BOM is not a BOM..."</li>
        </ul>
      </li>
      <li>Jens suggested that the wording needs to establish when encoding
          determination happens; that should be the first step of translation
          phase 1.</li>
      <li>Jens added that the wording should be consistent with regard to
          encoding vs encoding form vs encoding scheme.</li>
      <li>Tom stated that, for UTF-8, encoding form vs encoding scheme doesn't
          matter, but that encoding scheme should be used if the intent is for
          the wording to be compatible with UTF-16 or UTF-32.</li>
      <li>Hubert asserted that, since the context is byte oriented files,
          encoding scheme should be used.</li>
      <li>Jens reiterated the necessary wording updates; the encoding scheme to
          use must first be established, then the source file can be validated
          and diagnostics issued if it fails to conform to the encoding
          scheme.</li>
      <li>Jens added that the wording needs to prevent the current
          implementation-defined mapping to the internal encoding from being
          applied to UTF-8 source files.</li>
      <li>PBindels asked if the added sentence in translation phase 2 regarding
          the "first codepoint" applies to each source file or just to the
          primary source file.</li>
      <li>Tom and Corentin replied that translation phases 1 through 3 are
          performed separately for each source file.</li>
      <li>Hubert suggested that translation phase 2 should discard a lead
          U+FEFF character regardless of the source file encoding.</li>
      <li>Jens noted that the added translation phase 2 sentence doesn't make
          sense without the wording changes proposed in
          <a href="https://wg21.link/p2314">P2314: Character sets and encodings</a>
          due to character translation to <i>universal-character-name</i> in
          translation phase 1.</li>
      <li>Tom noted that the wording changes in P2314 allow distinguishing a
          source file with a BOM and a source file that starts with a
          <tt>\uFEFF</tt> <i>universal-character-name</i>.</li>
      <li>Jens clarified that, after P2314, a <i>universal-character-name</i>
          isn't translated to a UCS scalar value until translation phase 3.</li>
      <li>Hubert stated that it is a design question whether we want to treat a
          leading <tt>\uFEFF</tt> <i>universal-character-name</i> as a BOM.</li>
      <li>PBrett asked PBindels if he is satisfied with the BOM design
          following prior discussion.</li>
      <li>PBindels responded that he is, so long as we don't intentionally or
          unintentionally create the situation where UTF-8 source files end up
          requiring a BOM in practice.</li>
      <li>PBrett asked if we should add normative encouragement not to require
          a BOM.</li>
      <li>Hubert noted that, as wording updates are done, care must be taken to
          ensure we don't lose the wording that requires an implementation to
          accept a UTF-8 encoded source file whether it does, or does not,
          contain a BOM.</li>
      <li>Tom asked about handling of differently encoded source files.</li>
      <li>JeanHeyd replied in chat, "I think it's better to leave Encoding
          Identication to Tom's Paper on the subject."</li>
      <li>Tom replied in chat, "Assuming I actually deliver on that
          threat..."</li>
      <li>Hubert responded that the implementation must provide some means for
          standard headers (as opposed to header files), to remain usable when
          the implementation is running in UTF-8 mode.</li>
      <li>Steve added in chat, "Which might be 7 bit ascii for those headers.
          Which is largely the case today."</li>
      <li><b>We wish to require implementations to support UTF-8 source files.</b>
        <ul>
          <li><b>Attendance: 10</b></li>
          <li><b>No objections to unanimous consent.</b></li>
        </ul>
      </li>
      <li><b>We wish to require implementations to be capable of accepting UTF-8
          source files whether or not they begin with a U+FEFF byte order mark</b>.
        <ul>
          <li><b>Attendance: 10</b></li>
          <li><b>No objections to unanimous consent.</b></li>
        </ul>
      </li>
      <li>Hubert reported that Clang allows non-UTF-8 encoded header names in
          <tt>#include</tt> directives in otherwise UTF-8 encoded source
          files.</li>
      <li>Steve stated that, since file names are not required to be
          representable in UTF-8, requiring strictly well-formed UTF-8 could
          have unanticipated consequences.</li>
      <li>JeanHeyd asked in chat, "Does `\xFF` work in header-names as an
          escape?"</li>
      <li>Corentin replied in chat, "unspecified".</li>
      <li>Corentin explained his intent in requiring diagnosis of ill-formed
          UTF-8 input.</li>
      <li>PBindels asked why it is useful to allow invalid UTF-8 in
          comments.</li>
      <li>Corentin replied that Clang source code has comments explaining why
          invalid UTF-8 in comments is explicitly allowed and provided a link
          to the source code.
        <ul>
          <li><a href="https://github.com/llvm/llvm-project/blob/main/clang/lib/Lex/Lexer.cpp#L3136-L3144">https://github.com/llvm/llvm-project/blob/main/clang/lib/Lex/Lexer.cpp#L3136-L3144</a></li>
        </ul>
      </li>
      <li>PBrett shared cases of copyright symbols appearing in otherwise ASCII
          files.</li>
      <li>Tom noted that non-ASCII characters tend to appear in author, product,
          and company names in comments.</li>
      <li>Hubert stated that source files that <tt>iconv</tt> will reject are
          undesirable.</li>
      <li><b>We wish to require implementations to have a mode in which they diagnose ill-formed UTF-8 source files (regardless of whether the ill-formedness is located in comments, header names or string literals).</b>
        <ul>
          <li><b>Attendance: 10</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">8</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
        </ul>
      </li>
      <li><b>Consensus is strongly in favor.</b></li>
      <li><b>SF: As it stands right now, people are already basically rolling
          the dice with their source files. This is strictly an improvement
          over the status quo, because now there is, at least, one entirely
          portable way to write source code.</b></li>
      <li>Corentin asked about necessary wording to support both source files
          and non-files.</li>
      <li>Hubert responded that (standard library) headers are not source
          files; source files are those things that are included by
          <tt>#include</tt> directives that do not name standard headers.</li>
      <li>PBrett asked if the wording should be modified do discuss "input"
          as opposed to "files".</li>
      <li>Hubert responded that such a change is not necessary.</li>
      <li>Corentin pledged to bring back a revised paper.</li>
    </ul>
  <li>Tom stated the next telecon will be April 28th.</li>
</ul>


<h1 id="2021_04_28">April 28th, 2021</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://cplusplus.github.io/LWG/issue3547">LWG3547: Time formatters should not be locale sensitive by default</a></li>
  <li><a href="https://wg21.link/p2093r5">P2093R5: Formatted output</a></li>
  <li><a href="https://wg21.link/p2295r3">P2295R3: Support for UTF-8 as a portable source file encoding</a></li>
  <li><a href="https://wg21.link/p2348r0">P2348R0: Whitespaces Wording Revamp</a></li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Charlie Barto</li>
  <li>Corentin Jabot</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Mark Zeren</li>
  <li>Peter Bindels</li>
  <li>Peter Brett</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>Charlie Barto was welcomed with a round of introductions.</li>
  <li>PBrett introduced the agenda.</li>
  <li><a href="https://cplusplus.github.io/LWG/issue3547">LWG3547: Time formatters should not be locale sensitive by default</a>
    <ul>
      <li>PBrett presented:
        <ul>
          <li>Peter's presentation slides are available
              <a href="https://github.com/sg16-unicode/sg16-meetings/blob/master/presentations/2021-04-28-lwg3547-presentation.pptx">here</a>.</li>
          <li>As currently specified, whether a format specifier is locale
              dependent is not obvious.</li>
          <li>Floating point values are locale independent by default, but
              chrono values are not.</li>
          <li>There is no systematic way to format locale-independent and
              locale-dependent chrono values.</li>
        </ul>
      </li>
      <li>Victor expressed a preference for chrono values being locale
          independent by default.</li>
      <li>Victor explained that the current specification derived from existing
          specifiers used elsewhere.</li>
      <li>Victor noted that, in some cases, specifiers are not available for
          locale independent formatting.</li>
      <li>Victor reported success with a prototype implementation of the
          proposed resolution that performs locale independent formatting of
          chrono values unless a <tt>L</tt> specifier is present.</li>
      <li>Charlie stated that changes to the format specifier syntax may have
          more implementation impact than just requiring changes to the
          implementation behavior.</li>
      <li><em>[ Editor's note: Discussion regarding the amount of time
          available to make changes before implementations of
          <tt>std::format()</tt> are shipped to users ensued.  That discussion
          is not recorded as it involved discussion of internal company time
          lines that have not yet been stated in public. ]</em></li>
      <li>PBrett noted that there are two related issues:
        <ul>
          <li>1: The format specification syntax.</li>
          <li>2: The behavior of the format specifiers.</li>
        </ul>
      </li>
      <li>PBrett explained that the proposed resolution addresses both concerns
          by making the format syntax consistent in requiring a <tt>L</tt>
          specifier to opt-in to locale dependent behavior.</li>
      <li>Charlie noted that <tt>std::format()</tt> does not currently perform
          any transcoding operations today; not for format arguments, and not
          for text provided by a locale that uses a different character encoding
          than the literal encoding.</li>
      <li>Charlie added that <tt>std::format()</tt> does need to be encoding
          aware for the purposes of field width estimation.</li>
      <li>Corentin stated that the intent of the proposed resolution is to
          ensure that <tt>std::format()</tt> use consistent syntax to opt-in to
          locale dependent formatting and encouraged trying to address at least
          this concern.</li>
      <li>Corentin added that LWG might agree on a resolution in a short time
          frame, but that there will not be a plenary poll until June.</li>
      <li>PBrett stated that the resolution may be considered evolutionary.</li>
      <li>Victor agreed and noded that the <tt>L</tt> specifier could be added
          for a future standard.</li>
      <li>Victor asserted that we do need to decide what the default behavior
          is now.</li>
      <li>Victor added that we could consider transcoding locale provided text
          and potentially detecting mojibake if it would be produced.</li>
      <li>Victor noted that the format string is always a literal.</li>
      <li><em>[ Editor's note: In C++20, the format string may not be a literal,
          but
          <a href="https://wg21.link/p2216">P2216</a>,
          if adopted, will require a literal or other compile-time evaluated
          expression. ]</em></li>
      <li>Zach asked for clarification regarding what is meant by
          "default behavior" and noted that the <tt>%Ou</tt> specifier is
          locale dependent, but that <tt>%u</tt> is not.</li>
      <li>Victor responded that there are cases like <tt>%T</tt> that do not
          have locale independent forms.</li>
      <li><em>[ Editor's note: <tt>%T</tt> is locale dependent because the
          decimal point character potentially used for sub-second precision is
          provided by the locale. ]</em></li>
      <li>Hubert stated that these concerns will be difficult to resolve
          quickly, are clearly evolutionary, and may require balloting.</li>
      <li>Hubert added that there may also be issues with requiring the locale
          independent behavior to use English translations.</li>
      <li>Tom noted that the basic source character set already has a bias in
          English.</li>
      <li>Hubert responded that this goes further; we may potentially have to
          specify behavior in terms of <tt>asctime()</tt>.</li>
      <li>Charlie commented that the text provided by the locale facet is
          currently produced by the operating system; changing that behavior
          may not be problematic.</li>
      <li>Charlie added that adding new format specifiers will result in
          incompatibilities if code that uses those specifiers is run with an
          older library implementation that doesn't support them.</li>
      <li>Charlie noted that, if support for compile-time format string
          checking is adopted via
          <a href="https://wg21.link/p2216">P2216</a>,
          then the format string will become part of the function template
          specialization; this may help to avoid library compatibility
          issues.</li>
      <li>Charlie stated that there are multiple sources of locale information
          and that formatting of the chrono types is goverend by the Windows
          region settings.</li>
      <li>Charlie noted that changes to the Windows region settings require a
          reboot.</li>
      <li>Tom asked for confirmation that calls to <tt>std::setlocale()</tt>
          don't affect how chrono values are formatted.</li>
      <li>Charlie confirmed that is correct.</li>
      <li>PBrett asked if <tt>std::format()</tt> behavior is affected by
          changes to the global locale via <tt>std::locale::global()</tt>.</li>
      <li>Charlie responded that the global locale does affect the behavior of
          format specifiers that include the <tt>L</tt> specifier.</li>
      <li>Charlie clarified that the global locale will not affect parsing of
          the format string itself.</li>
      <li>Corentin requested review of the proposed resolution.</li>
      <li>Hubert noted that the wording requires that the "C" locale be used
          for field formats that do not include the <tt>L</tt> specifier
          regardless of whether a <tt>std::locale</tt> argument is passed.</li>
      <li>Hubert noted that under the C++20 wording, implementations trying to
          accomodate this tentative future direction may be more able to ignore
          the global locale than an explicit locale argument.  So, a change
          that maintains respecting the locale parameter is more compatible
          with C++20.</li>
      <li>Tom responded that doing so would not be consistent with the other
          standard format specifiers.</li>
      <li>Victor agreed and added that he would be strongly opposed to implicit
          use of a <tt>std::locale</tt> parameter.</li>
      <li>Jens stated that a migration path to better behavior needs to be
          estalished and noted that the current situation is an interesting
          mess.</li>
      <li>Jens suggested investigating how to increase consistency with the
          existing locale dependent format specifiers; e.g., for decimal
          point and digit group separator characters.</li>
      <li>Jens added that there may be cases where it would be useful to be
          able to specify use of the "C" locale even when a locale is provided
          as an argument.</li>
      <li>Jens observed that use of the "C" locale for the chrono <tt>%p</tt>
          specifier would be consistent with use of the "C" locale for floating
          point values.</li>
      <li>Jens noted that the example in the proposed resolution does not match
          the proposed grammar; the <tt>L</tt> specifier should precede the
          <i>chrono-specs</i> specifier, not follow it.</li>
      <li>Jens stated that adding support for the <tt>L</tt> specifier is
          backward compatible from a standard evolution perspective.</li>
      <li>Tom stated that a change to use the "C" locale in place of the global
          locale or a locale passed as an argument can be done as a non-abi
          breaking change.</li>
      <li>Charlie agreed, but noted that some implementation tricks may be
          required to avoid potential conflicts with older libraries.</li>
      <li>Zach stated that mixing different library versions is non-conforming
          anyway.</li>
      <li>Corentin stated that the "C" locale is used as a proxy for the
          absence of a locale and suggested that a constexpr locale might be
          desired in the future.</li>
      <li>Corentin asked Charlie if formatters can be modified without
          breaking ABI.</li>
      <li>Charlie replied that they are templates, so modifications can result
          in ODR violations.  Charled added that inline namespaces can be
          helpful in some cases.</li>
      <li>PBrett asked for confirmation that use of a <tt>L</tt> specifier
          where one is not expected will result in a format exception being
          thrown.</li>
      <li>Victor confirmed that is the case.</li>
      <li>PBrett asked if the <tt>L</tt> specifier could be reserved now such
          that a format exception will be thrown if used, and then different
          behavior specified later.</li>
      <li>Charlie responded that changing behavior to not throw in cases where
          an exception was previously thrown is fine so long as mixed library
          version problems are avoided.</li>
      <li>Victor expressed agreement with Jens' prior comments.</li>
      <li>Victor stated that behavior must remain consistent between
          <tt>std::format()</tt> overloads that do and do not accept
          <tt>std::locale</tt> arguments; the presence of the
          <tt>std::locale</tt> argument must not, by itself, affect
          behavior.</li>
      <li>PBrett suggested that a paper that explores the alternatives may be
          required.</li>
      <li>Corentin asserted that it must be possible to evolve the
          <tt>std::format</tt> format string so as to add new behaviors.</li>
      <li>Corentin expressed distaste for the idea of a "no locale" specifier;
          that approach would still result in inconsistencies with number
          formatting.</li>
      <li>Charlie agreed.</li>
      <li>Jens conceded that challenging standardization work will be required
          if behavior changes from C++20 to C++23.</li>
      <li>Jens asserted that the right to add format specifiers when a new
          standard is issued must be reserved, even if doing so causes
          implementation challenges.</li>
      <li><b>Poll 1: LWG3547 raises a valid design defect in [time.format] in C++20.</b>
        <ul>
          <li><b>Attendance: 11</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">7</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Consensus: Strong consensus that this issue represents a
              design defect.</b></li>
        </ul>
      </li>
      <li>Hubert noted that, with regard to issues of consistency, the proposed
          resolution is a departure from existing interfaces such as
          <tt>strftime()</tt>.</li>
      <li><b>Poll 2: The proposed LWG3547 resolution as written should be applied to C++23.</b>
        <ul>
          <li><b>Attendance: 11</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">0</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">1</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
          <li><b>SA: Mitigation of behavior changes sensitive to string literal
              contents is very difficult and there are options available to
              deal with this problem in an additive way; this direction
              represents an unnecessary backward compatibility break.</b></li>
        </ul>
      </li>
      <li>Mark stated that the proposed resolution would have been great 18
          months ago.</li>
      <li>PBrett responded that we need to recognize when we make mistakes
          and own correcting them.</li>
      <li>Corentin lamented the current state being another case of a bad
          default.</li>
      <li>Tom suggested that the current behavior can be presented as
          intentional with the goal to maintain consistency with existing
          interfaces; new format specifiers can then be added in C++23.</li>
      <li>PBrett suggested that an SG16 issue be filed and a volunteer found
          to work on it.</li>
      <li>Victor responded that the behavior isn't sufficiently broken to
          make him want to spend time on it.</li>
      <li><em>[ Editor's note: Despite that lack of desire, Victor and
          Corentin quickly authored an initial draft paper that will become
          <a href="https://wg21.link/p2372r0">P2372R0</a>
          once published. ]</em></li>
      <li>PBrett volunteered to work on a paper.</li>
    </ul>
  </li>
  <li>Tom and PBrett thanked Charlie for joining the telecon and encouraged
      him to continue attending.</li>
  <li>Tom stated that Victor had expressed interest in working on a potential
      <tt>std::locale</tt> replacement and asked if there were other
      volunteers interested in such work.
    <ul>
      <li>Victor responded that the motivation was provided by Hubert's
          example code included in the telecon agenda, that he is interested
          in conducting some implementation experiments, but that he does not
          have anything concrete in mind yet.</li>
      <li><em>[ Editor's note: Hubert's example is below.  In addition to the
          question of which locale is used in the formatting, there is a
          question of how encoding issues are handled.  The example depends on
          a locale to provide translations of AM/PM designators for a 12-hour
          clock.  What happens when the literal encoding is UTF-8 and the
          locale provides translations in Windows codepage 932?</em>
<pre style="display:inline"><tt>
    std::print("{:%r}\n", std::chrono::system_clock::now().time_since_epoch());
</tt></pre>
          <em>]</em>
      </li>
      <li>PBrett expressed interest in being involved.</li>
    </ul>
  </li>
  <li>Tom stated that the next SG16 telecon will be held May 12th.
    <ul>
      <li>Tom added that the agenda will include further discussion of
          <a href="https://wg21.link/p2093r5">P2093R5: Formatted output</a>
          and a return to
          <a href="https://wg21.link/p2295r3">P2295R3: Support for UTF-8 as a portable source file encoding</a>.</li>
      <li>PBrett asked if a CWG expert could review and comment on the updated
          wording for P2295R3.</li>
      <li>Hubert agreed to do so.</li>
      <li>Corentin requested a CWG expert also review the proposed wording in
          <a href="https://wg21.link/p2348r0">P2348R0: Whitespaces Wording Revamp</a>.</li>
  </li>
</ul>


<h1 id="2021_05_12">May 12th, 2021</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2295r3">P2295R3: Support for UTF-8 as a portable source file encoding</a></li>
  <li><a href="https://wg21.link/p2372r1">P2372R1: Fixing locale handling in chrono formatters</a></li>
  <li><a href="https://wg21.link/p2093r6">P2093R6: Formatted output</a></li>
  <li><a href="https://wg21.link/p2348r0">P2348R0: Whitespaces Wording Revamp</a></li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Charlie Barto</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Mark Zeren</li>
  <li>Peter Brett</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2295r3">P2295R3: Support for UTF-8 as a portable source file encoding</a>
    <ul>
      <li>No discussion as the author was not present.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2372r1">P2372R1: Fixing locale handling in chrono formatters</a>
    <ul>
      <li><em>[ Editor's note: D2372R1 was the active paper under discussion at
          the telecon.  That paper was later published as P2372R1 without
          further modification.  The agenda and links used here reference
          P2372R1 since the links to the draft paper were ephemeral.
          ]</em></li>
      <li>PBrett introduced the topic:
        <ul>
          <li>LEWG reached consensus for the direction proposed by
              <a href="https://wg21.link/p2372r0">P2372R0</a>
              at its
              <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/P2372#2021-05-03">2021-05-03 telecon</a>
              with additional refinement to preserve locale dependent
              formatting for iostreams.</li>
          <li>Since SG16 polls conduced at its
              <a href="https://github.com/sg16-unicode/sg16-meetings#april-28th-2021">2021-04-28 telecon</a>
              did not agree with this direction, LEWG requested that SG16
              review and conform or rebut the LEWG consensus.</li>
        </ul>
      </li>
      <li>Victor presented slides lightly updated from his prior LEWG
          presentation.
        <ul>
          <li>Victor's presentation slides are available
              <a href="https://github.com/sg16-unicode/sg16-meetings/blob/master/presentations/2021-05-12-p2372-presentation.pdf">here</a>.</li>
        </ul>
      </li>
      <li><b>Poll 1: Forward D2372R1 to LEWG for inclusion in C++23 and with
          the intent that it be applied retroactively to C++20.</b>
        <ul>
          <li><b>Attendance: 8</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">5</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Consensus: Strong consensus in favor.</b></li>
        </ul>
      </li>
      <li><em>[Editor's note: D2372R1 contains the LEWG requested update to
          preserve locale dependent formatting for ostreams. ]</em></li>
      <li><em>[Editor's note: The chair's perception is that SG16's change in
          consensus is attributable to two factors:
        <ol type="1">
          <li>New information that arrived after the initial poll.</li>
          <li>SG16's original poll targeted C++23 while LEWG's poll targets
              C++23 and C++20 as a DR; some concerns had been expressed
              regarding backward compatibility and migration.</li>
        </ol>
          ]</em>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2093r6">P2093R6: Formatted output</a>
    <ul>
      <li>Victor presented:
        <ul>
          <li><tt>std::print()</tt> integrates <tt>std::format()</tt> with
              I/O.</li>
          <li>R6 addresses recent LEWG feedback:
            <ul>
              <li>The proposed <tt>std::print()</tt> header was changed from
                  <tt>&lt;io&gt;</tt> to <tt>&lt;print&gt;</tt>.</li>
              <li>Additional rationale and clarifications were added regarding:
                <ul>
                  <li>Substitution of replacement characters.</li>
                  <li>The choice to base behavior on the compile-time literal
                      encoding.</li>
                  <li>ANSI escape sequences do not constitute a native device
                      API.</li>
                  <li>Existing practice in Rust.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
      </li>
      <li>PBrett asked how substitutions would be performed for different kinds
          of ill-formed scenarios.</li>
      <li>Zach stated that the Unicode standard documents recommended practice
          for substitution of replacement characters.</li>
      <li><em>[ Editor's note:
          <a href="http://www.unicode.org/versions/Unicode13.0.0">Unicode 13</a>
          discusses substitution of replacement characters in section
          "U+FFFD Substitution of Maximal Subparts" of
          chapter 3.9, "Unicode Encoding Forms" and in
          chapter 5.22, "U+FFFD Substitution in Conversion". ]</em></li>
      <li>Zach expressed a preference for implementations to be consistent in
          how replacement characters are substituted.</li>
      <li>Hubert stated that an example should be added to the paper.</li>
      <li>Hubert expressed a preference for <tt>vprint_unicode()</tt> to
          substitute replacement characters even when the output device is not
          Unicode.</li>
      <li>Victor asked if that could be done as implementation-defined
          behavior.</li>
      <li>Hubert responded, no; the goal is for the substitution behavior to be
          determinstic for <tt>vprint_unicode()</tt> regardless of the output
          device.</li>
      <li>Victor replied that he would prefer that behavior to be optional.</li>
      <li>Hubert replied that he would like to ensure that ill-formed inputs are
          not presented with no indication that something went wrong.</li>
      <li>PBrett stated that, when writing to a Unicode device, a
          <tt>U+FFFD</tt> replacement character should be substituted and the
          device should then handle it as its designers intended.</li>
      <li>Victor agreed with the substitution rationale for the device case
          since transcoding may be necessary, but disagreed for files due to a
          desire to avoid the validation overhead.</li>
      <li>Hubert expressed a preference for the behavior of
          <tt>vprint_unicode()</tt> to be consistent across files and
          devices.</li>
      <li>PBrett suggested that what Hubert desires is some kind of noisy
          failure, like a trap.</li>
      <li>Hubert agreed and restated the goal as some kind of signal that
          encoding issues were encountered.</li>
      <li>Steve stated that C++ programs do not typically interact directly
          with a device and that it is difficult to diagnose problems where the
          data can't be inspected en route.</li>
      <li>PBrett asked if Steve had a suggestion.</li>
      <li>Steve responded with a preference for a programatic error handling
          facility.</li>
      <li>Zach stated that, in the case where UTF-8 source is copied to a UTF-8
          sink, introduction of replacement characters could be surprising, but
          when transcoding is required, e.g., when the sink is UTF-16, then
          replacement characters are expected.</li>
      <li>Zach suggested decomposing the problem; validate and handle errors
          first, then convert.</li>
      <li>Charlie explained that, on Windows, the only ways to write Unicode to
          the console are to change the console encoding and write using the
          ANSI APIs, or to convert to UTF-16 and write using the wide APIs.</li>
      <li>Charlie noted that, since the console encoding is a global property
          of the process, changing it within <tt>std::print()</tt> would require
          synchronization.</li>
      <li>Zach suggested that it is reasonable to get mojibake in the ANSI case
          if the console encoding hasn't been correctly set.</li>
      <li>Hubert responded that the global console encoding condition seems to
          be particular to Windows and worth addressing.</li>
      <li>Charlie pondered the ramifications of writing to a stream opened in
          text mode.</li>
      <li>Victor reiterated his stance on not wanting to pay validation costs
          except in cases where transcoding is necessitated.</li>
      <li><b>Poll 2: When &lt;print&gt; facilities must transcode formatting
          results for display on a device and, during that process,
          invalidly-encoded text is encountered, <tt>std::print()</tt> should
          replace the erroneously-encoded code units with
          U+FFFD REPLACEMENT CHARACTER.</b>
        <ul>
          <li><b>Attendance: 9</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">3</th>
                <th style="text-align:right">3</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Consensus is in favor.</b></li>
          <li><b>A: Not convinced that silently substituting replacement
              characters is always the right policy; an exception could be
              appropriate.  There are parallels with integer overflow.</b></li>
          <li><b>A: Testing is difficult if substitution is device
              sensitive.</b></li>
        </ul>
      </li>
      <li>Charlie expressed support for a direction that would allow explicitly
          inhibiting use of the native device API but noted that, on Windows,
          that would mean the console encoding would have to be correctly set
          and the application would have to take care of buffering
          concerns.</li>
      <li><b>Poll 3: When &lt;print&gt; facilities need not transcode their
          formatting results for display on a device and invalidly-encoded text
          is encountered, <tt>std::print()</tt> should nevertheless replace the
          erroneously-encoded code units with U+FFFD REPLACEMENT CHARACTER.</b>
        <ul>
          <li><b>Attendance: 9</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">3</th>
              </tr>
            </table>
          </li>
          <li><b>N: Undecided due to uncertainty; more consideration is
              needed.</b></li>
          <li><b>A: Would prefer a UB approach that would enable sanitizers to
              diagnose these cases and remain conforming.</b></li>
          <li><b>SA: There is lack of implementation experience for this
              direction, it imposes overhead, and there are terminals that
              accept bytes.</b></li>
          <li><b>SA: A wide contract with validation does not make sense for
              high-performance I/O.</b></li>
        </ul>
      </li>
      <li>PBrett stated that there appear to be different audiences for
          <tt>std::print()</tt> and these audiences have different ideas of
          what is "obviously" correct:
        <ul>
          <li>For some, <tt>std::print()</tt> is a simple tool that enables a
              better Hello World.</li>
          <li>For others, it is a high-performance I/O facility.</li>
          <li>For yet others, it is a way to format bytes.</li>
        </ul>
      </li>
      <li>Tom suggested that an error handling facility might move us
          towards more consensus.</li>
      <li>PBrett noted that something like JeanHeyd's transcoding facilities
          could provide that.</li>
      <li>Charlie agreed that integration of a familiar transcoding facility
          could work.</li>
    </ul>
  </li>
  <li>Tom stated that the next telecon will be May 26th and that the agenda
      will again include
      <a href="https://wg21.link/p2295r3">P2295R3</a>
      and
      <a href="https://wg21.link/p2093r6">P2093R6</a>.</li>
</ul>


<h1 id="2021_05_26">May 26th, 2021</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2295r4">P2295R4: Support for UTF-8 as a portable source file encoding</a>
    <ul>
      <li>Review updates intended to address prior SG16 feedback.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2093r6">P2093R6: Formatted output</a>
    <ul>
      <li>Discuss locale dependent character encoding concerns.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Corentin Jabot</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Mark Zeren</li>
  <li>Peter Brett</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2295r4">P2295R4: Support for UTF-8 as a portable source file encoding</a>
    <ul>
      <li><em>[ Editor's note: D2295R4 was the active paper under discussion at
          the telecon.  The agenda and links used here reference
          P2295R4 since the links to the draft paper were ephemeral.  The
          published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>PBrett provided an introduction.</li>
      <li>Corentin presented and described the changes from R3 to the
          draft R4.</li>
      <li>PBrett observed that the wording updates removed the prior
          definition for a <i>UTF-8 file</i> and added a new definition for
          a <i>UTF-8 source file</i>.</li>
      <li>Tom recalled prior discussion that suggested there was no need to
          provide such a definition at all.</li>
      <li>Jens confirmed and explained that the prior suggestion was to
          instead specify translation phase 1 in terms of a sequnce of
          characters instead.</li>
      <li>Jens noted that there will be merge conflicts with
          <a href="https://wg21.link/p2314">P2314</a>.</li>
      <li>Corentin asked if the merge conflicts can be dealt with after CWG
          reviews P2314.</li>
      <li>Jens confirmed that they can be.</li>
      <li>PBrett asked if progress can be made before P2314 is adopted into
          the working paper.</li>
      <li>Jens confirmed that progress can be made.</li>
      <li>PBrett asked Jens if he would like to see additional wording changes
          reviewed in SG16.</li>
      <li>Jens replied that he would and noted that he had not received a
          response to all of the suggestions previously provided in his message
          to the mailing list available at
          <a href="https://lists.isocpp.org/sg16/2021/04/2353.php">https://lists.isocpp.org/sg16/2021/04/2353.php</a>.</li>
      <li>Jens observed that the proposed wording results in existing wording
          no longer applying to all source files.  For example, "Any source
          file character not in the basic source character set is replaced by
          the <i>universal-character-name</i> that designates that character"
          now appears in a paragraph that doesn't apply to UTF-8 source
          files.</li>
      <li>Corentin responded that this paper doesn't make sense without the
          changes from P2314.</li>
      <li>Tom asked if the wording could be rebased on P2314 with a noted
          dependency on P2314.</li>
      <li>Jens replied that it could be.</li>
      <li>Hubert noted that the definition of a UTF-8 source file is problematic
          since the definition could apply to a file that just so happens to
          decode as UTF-8, but is not intended as a UTF-8 file.</li>
      <li>PBrett responded that the following sentence specifies that encoding
          determination is implementation-defined.</li>
      <li>Hubert acknowledged and suggested it might be helpful to reorder the
          sentences.</li>
      <li>Hubert added that wording is still required to reflect intent that a
          file be interpreted as UTF-8.</li>
      <li>PBrett agreed by way of an example; an implementation invoked without
          such intent may analyze a file, determine that it does not decode
          successfully as UTF-8, and then interpret it as, for example,
          Windows-1252, and do so without issuing a diagnostic.</li>
      <li>Jens observed that the wording states that, "An implementation shall
          support UTF-8 source files", but there is no wording to require
          diagnosis of ill-formed UTF-8 source files.</li>
      <li>Corentin responded that there is no such thing as an invalid UTF-8
          file; either a file is valid UTF-8 or it is not UTF-8.</li>
      <li>Mark responded that there is a desire to have implementations produce
          a diagnostic if source files that are purported to be encoded as
          UTF-8 are not, in fact, valid UTF-8.</li>
      <li>PBrett stated that there are three distinct requirements:
        <ul>
          <li>A requirement to support UTF-8 encoded source files.</li>
          <li>A requirement for means to inform the implementation that all
              source files are to be assumed to be UTF-8 encoded.</li>
          <li>A requirement that the implementation diagnose files that were
              assumed to be UTF-8 encoded but that contain (some) non-UTF-8
              content.</li>
        </ul>
      </li>
      <li>Hubert offered some suggested wording in chat:
        <ul>
          <li>"An implementation shall provide for processing physical source
              files as having a UTF-8 encoding scheme without restriction,
              other than resource limits ([implimits]), upon the content of
              the physical source file."</li>
        </ul>
      </li>
      <li>Jens pasted previously suggested wording from the mailing list in
          chat:
        <ul>
          <li>"The encoding scheme of a physical source file is determined in
              an implementation-defined manner.  An implementation shall
              support (possibly among others) the UTF-8 encoding scheme."</li>
          <li>"If the encoding scheme of a physical source file is determined
              to be UTF-8, the physical source file shall consist of a
              well-formed sequence of UTF-8 code units as specified by ISO/IEC
              10646."</li>
        </ul>
      </li>
      <li>Hubert expressed support for that wording but thought some additional
          updates would still be required to ensure diagnostics.</li>
      <li>Corentin disagreed with removal of wording that requires that the
          scalar value of source file characters be preserved.</li>
      <li>Jens responded that the scalar value preservation wording isn't
          required because the mapping to the translation character set already
          preserves characters.</li>
      <li>Steve noted the existence of wording that uses the phrase "known to
          the implementation" and asked if that could be used to specify how
          source file encoding is determined.</li>
      <li>Tom suggested that implementation-defined is preferred since that
          reflects a documentation requirement.</li>
      <li>Hubert added that the "known to the implementation" wording is not
          intended to reflect that implementations can be wrong.</li>
      <li>PBrett observed that Jens and Hubert would presumably like to see
          updated wording.</li>
      <li>Hubert expressed a belief that the required wording has been
          identified and that he is onboard with the goal of preserving scalar
          value sequences from UTF-8 source files.</li>
      <li>Corentin responded that he will bring back a revised paper with the
          suggested wording.</li>
      <li>Steve informed the group that the EWG chair is considering dedicating
          a telecon to SG16 papers in the next month or so.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2093r6">P2093R6: Formatted output</a>
    <ul>
      <li>PBrett reported a previous conversation with Victor in which Victor
          expressed that he felt he has the guidance he needs regarding
          handling of substitution characters and locale.</li>
      <li>Victor presented slides:
        <ul>
          <li>The next question to be answered is whether it is ok to base
              behavior on the literal encoding.</li>
          <li>Use of the literal encoding avoids race conditions with locale
              settings.</li>
        </ul>
      </li>
      <li>Discussion ensued regarding current dependencies on the choice of
          literal encoding and it was observed that, though the wording
          provided by
          <a href="https://wg21.link/p1868">P1868</a>
          to specify estimated format field widths is not based on the literal
          encoding, at least one implementation is planning to only use the
          specified estimated widths when the literal encoding is UTF-8.</li>
      <li>Hubert observed that field width estimation can apply to content
          from other than string literals.</li>
      <li>PBrett provided an example; when <tt>gettext()</tt> is used, a
          literal is used for the message catalog lookup, but the result is
          not a string literal.</li>
      <li>Hubert acknowledged the provided rationale, but noted that it does
          not address concerns raised and that he has seen many cases where
          use of locales works fine on UNIX systems.</li>
      <li>Hubert added that this has the potential to bite existing users since
          code may appear to work correctly until it suddenly doesn't.</li>
      <li>Victor replied that his goal is to make UTF-8 cases work as expected
          and that he is willing to accept some surprises in other
          scenarios.</li>
      <li>Victor stressed that the intention is that, on UNIX systems, bytes
          are simply passed through.</li>
      <li>Tom directed discussion towards the example code from the
          <a href="https://lists.isocpp.org/sg16/2021/05/2389.php">telecon announcement</a>.</li>
      <li>Victor stated that he will request a LWG issue or author a paper to
          address handling of locale provided text.</li>
      <li><em>[ Editor's note: Victor requested an LWG issue that is now
          tracked as
          <a href="https://wg21.link/lwg3565">LWG issue 3565</a>. ]</em></li>
      <li>Corentin stated that he is content with undefined behavior for cases
          where UTF-8 input is expected, but the input is not actually
          UTF-8 encoded.</li>
      <li>Hubert responded that the format locale situation is rather urgent
          for EBCDIC environments.</li>
      <li>PBrett stated that he is ok with the proposal because it won't break
          anything worse than it already is.</li>
    </ul>
  </li>
  <li>Tom stated that the next telecon will be held on June 9th.</li>
</ul>


</body>
