<!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 2023-10-11 through 2024-02-21</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 style="max-width: 8.5in">

<table id="header">
  <tr>
    <th>Document Number:</th>
    <td>P3174R0</td>
  </tr>
  <tr>
    <th>Date:</th>
    <td>2024-03-09</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 2023-10-11 through 2024-02-21</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="#2023_10_11">
      October 11th, 2023</a></li>
  <li><a href="#2023_10_25">
      October 25th, 2023</a></li>
  <li><a href="#2023_11_29">
      November 29th, 2023</a></li>
  <li><a href="#2024_01_10">
      January 10th, 2024</a></li>
  <li><a href="#2024_01_24">
      January 24th, 2024</a></li>
  <li><a href="#2024_02_07">
      February 7th, 2024</a></li>
  <li><a href="#2024_02_21">
      February 21st, 2024</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>
  <li><a href="https://wg21.link/p2397">P2397: SG16: Unicode meeting summaries 2021-04-14 through 2021-05-26</a></li>
  <li><a href="https://wg21.link/p2512">P2512: SG16: Unicode meeting summaries 2021-06-09 through 2021-12-15</a></li>
  <li><a href="https://wg21.link/p2605">P2605: SG16: Unicode meeting summaries 2022-01-12 through 2022-06-08</a></li>
  <li><a href="https://wg21.link/p2678">P2678: SG16: Unicode meeting summaries 2022-06-22 through 2022-09-28</a></li>
  <li><a href="https://wg21.link/p2766">P2766: SG16: Unicode meeting summaries 2022-10-12 through 2022-12-14</a></li>
  <li><a href="https://wg21.link/p2891">P2891: SG16: Unicode meeting summaries 2023-01-11 through 2023-05-10</a></li>
  <li><a href="https://wg21.link/p2995">P2995: SG16: Unicode meeting summaries 2023-05-24 through 2023-09-27</a></li>
</ul>
</p>


<h1 id="2023_10_11">October 11th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p1729r3">P1729R3: Text Parsing</a>:
    <ul>
      <li>Continue review.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Corentin Jabot</li>
  <li>Elias Kosunen</li>
  <li>Hubert Tong</li>
  <li>Nathan Owen</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p1729r3">P1729R3: Text Parsing</a>:
    <ul>
      <li><em>[ Editor's note: D1729R3 was the active paper under discussion at
          the telecon.
          The agenda and links used here reference P1729R3 since the links to
          the draft paper were ephemeral.
          The published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>Elias presented the changes in the draft P1729R3:
        <ul>
          <li><tt>std::scan</tt> now returns a subrange for the unparsed input
              rather than just an iterator to the start of the range.</li>
          <li>As noted in the revision history, changes requested during the
              last SG16 review with respect to whitespace, locale, and encoding
              concerns have been made.</li>
        </ul>
      </li>
      <li>Victor asked if returning a subrange will be less efficient since it
          requires passing an iterator pair or an iterator and size pair.</li>
      <li>Elias responded that the overhead is expected to be negligible
          relative to the convenience provided by returning the sentinel.</li>
      <li>Elias commented that, per section 3.6, "Scanning an user-defined type",
          the second template parameter for <tt>std::scanner</tt> now has
          <tt>char</tt> as a default argument.</li>
      <li>Elias reviewed the changes in section 4.2, "Format strings" to define
          whitespace in terms of the Unicode <tt>Pattern_White_Space</tt>
          property.</li>
      <li>Victor asked why LEFT-TO-RIGHT MARK and RIGHT-TO-LEFT MARK are
          considered whitespace.</li>
      <li>Robin responded that these code points can be used to prevent
          directionality properties from one token from affecting how the
          characters of an adjacent token are displayed.</li>
      <li>Tom asked for confirmation that there is no desire or need for
          scanning to consider bidirectional concerns; e.g., scanning should
          always follow memory order, not logical order.</li>
      <li>Robin referenced the examples in
          <a href="https://www.unicode.org/reports/tr55/tr55-3.html#Usability-bidi">section 1.3.2, "Usability issues arising from bidirectional reordering"</a>
          of
          <a href="http://www.unicode.org/reports/tr55">UTS #55, "Unicode Source Code Handling"</a>
          that demonstrate how the Unicode Bidirectional Algorithm can produce
          unreadable text.</li>
      <li>Victor requested the addition of some bidirectional examples and asked
          Robin if he could offer some suggestions that would be relevant for
          scanning.</li>
      <li>Robin responded in chat to see the examples in
          <a href="https://www.unicode.org/reports/tr31/tr31-39.html#Bidirectional_Ordering">section 4.1.1, "Bidirectional Ordering"</a>
          of
          <a href="https://www.unicode.org/reports/tr31">UAX #31, "Unicode Identifiers and Syntax"</a>.</li>
      <li>Elias agreed that examples can be added.</li>
      <li>Tom noted that, when the input is not known to be in a UTF encoding,
          that the set of whitespace characters will need to be
          implementation-defined.</li>
      <li>Elias agreed and stated those details will be added later.</li>
      <li>Elias directed attention to section 4.3.5.1,
          "Design discussion: Thousands separator grouping checking" and noted
          that iostreams enforces grouping separators.</li>
      <li>Tom asked for confirmation that iostreams only enforces that, if
          grouping separators are present, that they are in the expected
          locations and that they aren't required to be present.</li>
      <li>Elias confirmed.</li>
      <li>Victor asserted that <tt>std::scan</tt> should do what iostreams does
          and stated that programmers that want different behavior can implement
          that themselves.</li>
      <li>Elias suggested the behavior could potentially be changed later if
          desired.</li>
      <li>Victor replied that it is generally more difficult to introduce an
          error where one was not previously reported than it is to relax an
          error that was previously reported.</li>
      <li>Elias noted that some <tt>scanf()</tt> implementations have an
          extension that allows <tt>'</tt> to be recognized as a grouping
          separator.</li>
      <li>Tom asked if that separator is handled like it is in C++ where it can
          appear anywhere any number of times.</li>
      <li>Elias responded that it is recognized as an alternate grouping
          separator, so no.</li>
      <li>Victor explained that
          <a href="https://github.com/fmtlib/fmt">{fmt}</a>
          briefly supported that feature but that it was removed.</li>
      <li>Victor opined that support for that feature probably isn't
          needed.</li>
      <li>Elias acknowledged that support for it could always be added
          later.</li>
      <li>Corentin agreed with Victor, expressed a desire to eventually replace
          locale support with something based on ICU someday, and encouraged
          avoidance of innovation with locale features.</li>
      <li>Elias stated that he would not proceed further with the alternate
          separator.</li>
      <li>Elias pointed out that section 4.5,
          "Argument passing, and return type of <tt>scan</tt>", now specifies
          that <tt>std::scan</tt> returns a subrange.</li>
      <li>Elias observed a markup error in the last paragraph of that section;
          "gt;" appears where "&amp;gt;" was intended to encode "&gt;".</li>
      <li>Elias claimed that the return of a subrange consisting of an iterator
          and sentinel pair is novel and is done because the sentinel is always
          available but converting it to an iterator would require more work to
          advance an iterator to the sentinel position.</li>
      <li>Tom encouraged Elias to contact the SG9 chair to arrange a
          discussion.</li>
      <li>Elias proclaimed that a better name is needed for the proposed
          <tt>borrowed_ssubrange_t</tt> and explained that the extra "s" stands
          for sentinel.</li>
      <li>Steve agreed and stated that, as is, that name looks like a typo.</li>
      <li>Steve recommended spelling the name out since this isn't one that
          programmers would have to write often anyway.</li>
      <li>Corentin suggested that it might be possible to change
          <tt>borrowed_subrange</tt> to support an iterator and sentinel
          subrange.</li>
      <li>Elias replied that doing so might impact ABI.</li>
      <li>Corentin recommended discussing it in SG9.</li>
      <li>Elias presented section 4.6, "Error handling", and the recently added
          <tt>value_out_of_range</tt> enumerator added to
          <tt>scan_error::code_type</tt>.</li>
      <li>Elias explained that the <tt>strtol()</tt> family of interfaces allow
          a programmer to differentiate between overflow and underflow using a
          combination of the return value and <tt>errno</tt>, but that
          <tt>std::scan</tt> as proposed would not be able to support that.</li>
      <li>Victor reported having previously needed to be able to differentiate
          between underflow and overflow.</li>
      <li>Tom stated that it sounds like there is some motivation for more
          granular errors.</li>
      <li>Corentin argued that isn't a question for SG16 to answer.</li>
      <li>Elias reported that there are a lot of potential error conditions and
          argued that adding a different error code for each is probably
          undesirable.</li>
      <li>Corentin asked if a distinct error code is needed for encoding
          errors.</li>
      <li>Elias responded that there had been discussion about that during the
          previous review and that we'll get to that section shortly.</li>
      <li>Corentin asserted that it would be useful to provide an iterator or
          index to the position within the input where an error occurred.</li>
      <li>Victor agreed.</li>
      <li>Victor suggested it would make sense to provide more granular error
          handling for builtin types.</li>
      <li>Victor requested some additional examples and noted that there are
          unique error cases for floating-point types.</li>
      <li>Elias mentioned that an example has been added to section 4.10,
          "Locales".</li>
      <li>Elias stated that section 4.11, "Encoding" was added for the R3
          revision.</li>
      <li>Elias summarized discussion from the last SG16 review; that
          ill-formed code unit sequences be handled similar to floating-point
          NaN values in that they don't match anything.</li>
      <li>Victor suggested that "invalidly encoded code points" should be
          changed to something like "ill-formed code unit sequences".</li>
      <li>Corentin asked if the intent is to supply replacement characters for
          ill-formed code unit sequences.</li>
      <li>Elias replied negatively and explained that the intent is to allow
          use of <tt>std::string_view</tt> as a result type that refers to
          matched characters in the input; that support precludes substitution
          of replacement characters.</li>
      <li>Elias stated that these sequences are instead handled like
          non-characters.</li>
      <li>Elias acknowledged that this design means that unsanitized input
          won't be validated and that ill-formed code unit sequences may
          persist in the output.</li>
      <li>Corentin noted the implication; that values returned by
          <tt>std::scan</tt> can't be trusted and lack of verification can
          result in UB and security issues.</li>
      <li>Elias agreed that there is a security aspect since the input could
          be arbitrary user provided input.</li>
      <li>Victor opined that the proposed behavior seems reasonable and
          consistent with other scan-like functions.</li>
      <li>Victor suggested updating the paper to compare the proposed behavior
          with <tt>scanf()</tt>.</li>
      <li>Steve noted that, even if the input was mutable, rewriting replacement
          characters into the buffer is not an option since the space needed for
          the encoded replacement character might require a longer buffer.</li>
      <li>Steve explained that Zach's proposed transcoding facilities could be
          used to pipe input that has not been validated for encoding concerns
          into the scanner such that replacement characters are proactively
          substituted.</li>
      <li><em>[ Editor's note: The input produced by such a pipeline would not
          provide a contiguous range of elements and would presumably not be
          usable with a <tt>std::string_view</tt> result type. ]</em></li>
      <li>Steve expressed a preference for features that compose.</li>
      <li>Victor asserted that it should be possible to use <tt>std::scan</tt>
          with binary data and that ill-formed code unit sequences should
          therefore not be unconditionally rejected.</li>
      <li>Corentin agreed that support for binary data is an important concern
          and referred to a comment
          <a href="https://lists.isocpp.org/sg16/2023/10/3974.php">Tom made in a message to the SG16 mailing list</a>
          about the potential use of a <tt>{:?}</tt> format specier for byte
          precise scanning.</li>
      <li>Corentin expressed uncertainty regarding how important it is to handle
          mixed binary and text.</li>
      <li>Corentin noted that the proposed design provides different guarantees
          for different types; result objects of <tt>int</tt> and <tt>float</tt>
          type will always hold valid values, but a string type might hold
          garbage.</li>
      <li>Corentin worried that programmers might expect a validly encoded
          string and be surprised.</li>
      <li>Victor claimed that it is not possible to determine what is and is
          not garbage since programmers do use string types like
          <tt>std:string_view</tt> with binary data.</li>
      <li>Victor asserted that we should not try to guess the programmer's
          intent.</li>
      <li>Tom agreed that we should not assume the programmer's intent and
          observed that providing a facility to allow them to express their
          intent could be ok.</li>
      <li>Elias reported that the example that Tom included in the
          <a href="https://lists.isocpp.org/sg16/2023/10/3971.php">agenda announcement</a>
          has been added as example 6 in section 4.3.8,
          "Type specifiers: CharT".</li>
      <li><em>[ Editor's note: the example involves a scan of the first code
          unit of a multiple code unit sequence followed by a scan of a string
          that then interprets the remainder of the code unit sequence as an
          ill-formed sequence. ]</em></li>
      <li>Corentin noted that scanning strings requires recognizing spaces and
          asked if there is a use case for a space separated sequence of random
          bytes.</li>
      <li>Corentin surmised that, if that use case is important, then it should
          influence the design.</li>
      <li>Victor recognized Corentin's observation regarding spaces and random
          bytes as important.</li>
      <li>Victor stated that the behavior described for the example in the paper
          matches his expectations.</li>
      <li>Elias argued that the entire input should not be sanitized due to
          processing overhead.</li>
      <li>Elias affirmed that an invalidly encoded string could be handled as
          an error.</li>
      <li>Tom asserted it would be useful to allow the programmer to express
          their intent with a type specifier.</li>
      <li>Tom noted that the ability to do so would allow for the kinds of
          encoding guarantees that programmers might expect and argued that this
          should be the default behavior.</li>
      <li>Elias agreed that would be useful.</li>
      <li>Elias stated that he will have to evaluate further how that fits into
          the design but that it sounds manageable.</li>
      <li>Tom asked if <tt>signed char</tt> and <tt>unsigned char</tt> are
          handled as character or integer types.</li>
      <li>Elias responded that they are treated as integer types.</li>
      <li>Tom noted that is consistent with <tt>std::format()</tt>.</li>
      <li>Elias added that it is also consistent with iostream.
      <li>Victor conveyed a lack of enthusiasm for an additional format
          specifier due to the increased complexity.</li>
      <li>Tom suggested relying on the type system instead; perhaps
          <tt>std::span&lt;char&gt;</tt> could be used to scan a
          "binary string".</li>
      <li>Victor agreed and suggested there could be another type to represent
          a broken code unit.</li>
      <li>Corentin nominated <tt>std::byte</tt>.</li>
      <li>Tom noted that <tt>std::byte</tt> wouldn't work for wide strings.</li>
      <li>Corentin countered that wide strings aren't used for binary data.</li>
      <li>Tom responded that a programmer might want to be able to read a lone
          surrogate.</li>
      <li>Victor reported that <tt>std::format()</tt> formats <tt>std::byte</tt>
          as an unsigned integer.</li>
      <li>Tom summarized his impression of the consensus at this point;
          the design is good, but some progress is needed regarding handling of
          text vs binary input.</li>
      <li>Corentin expressed a penchant for the design in general.</li>
      <li>Elias requested that the meeting minutes be published before October
          15th so that they would be available for reference by the R3 paper in
          time for the next mailing deadline.</li>
      <li>Tom said he would try.</li>
      <li><em>[ Editor's note: Tom provided a rough draft of the minutes prior
          to the 15th and that sufficed for Elias' purposes. ]</em></li>
    </ul>
  </li>
  <li>Tom announced that the next meeting will be held 1023-10-25 and that there
      are some LWG issues to be discussed, including ones involving everyone's
      favorite locale facet, <tt>std::codecvt</tt>.</li>
  <li>Hubert stated that he might soon have a paper that discusses use of
      <tt>$</tt> in identifiers.</li>
</ul>


<h1 id="2023_10_25">October 25th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li>charN_t, char_traits, codecvt, and iostreams:
    <ul>
      <li><a href="https://wg21.link/p2873r0">P2873R0: Remove Deprecated Locale Category Facets For Unicode from C++26</a>.</li>
      <li><a href="https://wg21.link/lwg3767">LWG 3767: codecvt&lt;charN_t, char8_t, mbstate_t&gt; incorrectly added to locale</a>.</li>
      <li><a href="https://wg21.link/lwg2959">LWG 2959: char_traits&lt;char16_t&gt;::eof is a valid UTF-16 code unit</a>.</li>
        <ul>
          <li><a href="https://github.com/sg16-unicode/sg16/issues/32">SG16 #32: std::char_traits&lt;char16_t&gt;::eof() requires uint_least16_t to be larger than 16 bits</a>.</li>
        </ul>
      </li>
      <li><a href="https://github.com/sg16-unicode/sg16/issues/33">SG16 #33: A correct codecvt facet that works with basic_filebuf can't do UTF conversions</a>.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Alisdair Meredith</li>
  <li>Corentin Jabot</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Nathan Owens</li>
  <li>Peter Brett</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>PBrett announced that he will be retiring from C++ standardization efforts
      for the foreseeable future starting in November.</li>
  <li>Several people voiced disappointment and wished Peter well.</li>
  <li>charN_t, char_traits, codecvt, and iostreams:
    <ul>
      <li>Tom reported having reached out to the WG21 ABI review group to ask if
          there were any known ABI tricks that implementors might deploy if
          <a href="https://wg21.link/lwg2959">LWG 2959 (char_traits&lt;char16_t&gt;::eof is a valid UTF-16 code unit)</a>
          were to be fixed in the obvious way; by mapping the <tt>int_type</tt>
          member alias to a larger type.</li>
      <li>Tom summarized their response; no tricks were identified; suggestions
          included defining a replacement type for the
          <tt>std::char_traits&lt;char16_t, char, std::mb_state&gt;</tt>
          specialization that could be explicitly used in its place.</li>
      <li>Corentin replied that a replacement type doesn't solve the user
          problem.</li>
      <li>Corentin reported intent to submit a proposal to deprecate user
          specializations of <tt>std::char_traits</tt>.</li>
      <li>Corentin asked if Tom had asked the libc++ maintainers directly
          regarding their thoughts on the issue.</li>
      <li>Tom reported that he has not.</li>
      <li>Corentin suggested that doing so might be helpful.</li>
      <li>Tom reported having audited uses of the <tt>int_type</tt> and related
          members of <tt>std::char_traits</tt> throughout the standard and
          having found that they are only used within iostreams and, since the
          standard only requires iostreams to support <tt>char</tt> and
          <tt>wchar_t</tt>, changing <tt>int_type</tt> for the <tt>char16_t</tt>
          specialization appears to be a viable option.</li>
      <li><em>[ Editor's note: Tom's audit rediscovered information that was
          already known and had been reported in
          <a href="https://github.com/sg16-unicode/sg16/issues/32#issuecomment-433877435">a comment on SG16 issue #32</a>
          back in 2018. ]</em></li>
      <li>Hubert stated that the libc++ implementation of iostreams uses the
          <tt>eof()</tt> member of <tt>std::char_traits</tt> as a sentinel value
          to determine if a fill character has been specified via the
          <tt>std::setfill()</tt> I/O manipulator.</li>
      <li><em>[ Editor's note: The libc++ implementation of
          <tt>std::basic_ios</tt> has a private data member named
          <tt>__fill_</tt> of type <tt>int_type</tt> that is initlialized to
          <tt>eof()</tt>.
          When a fill character is needed, a comparison is performed against
          <tt>eof()</tt> to determine if a fill character has been set or
          whether the (possbily widened) default fill character should be used.
          ]</em></li>
      <li>Hubert noted this as an issue for the <tt>wchar_t</tt> iostream and
          <tt>std::char_traits</tt> specializations.</li>
      <li>Tom noted that, for <tt>wchar_t</tt> the EOF value is specified by
          <tt>WEOF</tt> and asked if it is known to have a value other than
          -1 anywhere.</li>
      <li>Hubert responded that he was not aware of other values being used,
          but that the value is problematic because programmers can use that
          value.</li>
      <li><em>[ Editor's note: Microsoft's <tt>wchar.h</tt> header defines
          <tt>WEOF</tt> as <tt>((wint_t)(0xFFFF))</tt> which is equivalent to
          <tt>-1</tt> converted to <tt>wint_t</tt> (<tt>unsigned short</tt>).
          ]</em></li>
      <li>Tom acknowledged the concern as applicable to the <tt>wchar_t</tt>
          specialization and that it can be treated as a separable issue.</li>
      <li>Corentin reported that the C++ standard appears to be missing a
          definition for <tt>WEOF</tt>.</li>
      <li>Jens responded that the C++ standard has an exposition value of
          "*see below*" that is intended to redirect to the C library.</li>
      <li>Jens noted the redirection is the same as for <tt>wint_t</tt>.</li>
      <li><em>[ Editor's note: See
          <a href="http://eel.is/c++draft/cwctype.syn#lib:WEOF">[cwctype.syn]</a>
          and
          <a href="http://eel.is/c++draft/cwchar.syn#lib:WEOF">[cwchar.syn]</a>.
          ]</em></li>
      <li>Tom observed that the clash with <tt>WEOF</tt> is only a problem when
          the <tt>WEOF</tt> value is in the range of <tt>wchar_t</tt> values;
          e.g., when <tt>WEOF</tt> is -1 and <tt>wchar_t</tt> is a signed
          type.</li>
      <li>Jens noted that the C standard requires that <tt>wint_t</tt> be able
          to hold all extended character values and that Hubert's concern is
          that C++ extends more flexibility to users in use of particular
          values.</li>
      <li>Tom indicated that he would work with Hubert to get an issue
          filed.</li>
      <li>Corentin stated that <tt>std::char_traits&lt;wchar_t&gt;</tt> also
          suffers from the lack of an available value for EOF in implementations
          like Microsoft's where both <tt>wchar_t</tt> and <tt>wint_t</tt> are
          16-bit and used with UTF-16.</li>
      <li><em>[ Editor's note: Microsoft's implementation uses an unsigned
          16-bit type for both <tt>wchar_t</tt> and <tt>wint_t</tt>, defines
          <tt>WEOF</tt> as <tt>((wint_t)(0xFFFF))</tt>, <tt>WCHAR_MIN</tt> as
          <tt>0</tt>, and <tt>WCHAR_MAX</tt> as <tt>0xFFFF</tt>.
          That leaves no values left for use as an EOF sentinel. ]</em></li>
      <li>Hubert expressed skepticism that such implementations are
          conforming.</li>
      <li>Jens recalled that changes were made to allow for use of UTF-16 with
          <tt>wchar_t</tt> at the core language level but that such allowances
          were not extended to the standard library.</li>
      <li><em>[ Editor's note: see
          <a href="https://wg21.link/p2460">P2460 (Relax requirements on <tt>wchar_t</tt> to match existing practices)</a>.i
          ]</em></li>
      <li>Jens acknowledged that the distinction doesn't matter much since
          existing implementations are not going to be changed.</li>
      <li>Tom expressed a preference to fix <tt>char_traits&lt;char16_t&gt;</tt>
          as a technically breaking change.</li>
      <li>Jens requested that implementors be directly contacted for
          feedback.</li>
      <li>Hubert also encouraged Jens' request since a change would break use of
          libc++ iostreams with <tt>char16_t</tt>.</li>
      <li>Jens acknowledged the potential break, but noted that the ability to
          use iostreams with <tt>char16_t</tt> might not be intentional.</li>
      <li>Jens presented <tt>std::complex</tt> as an example of a class template
          that has restrictions on which types are allowed as template type
          arguments.</li>
      <li>Alisdair stated that there are a number of class templates for which
          instantiations are only guaranteed to work with certain types.</li>
      <li>Tom asked for confirmation that <tt>std::regex</tt> is limited to
          instantiations with <tt>char</tt> and <tt>wchar_t</tt>.</li>
      <li>Alisdair confirmed that is his understanding.</li>
      <li>Corentin noted that fixing <tt>std::regex</tt> to properly support
          Unicode would require an ABI break.</li>
      <li>Tom turned discussion towards the issues concerning
          <tt>std::codecvt</tt>.</li>
      <li>Tom asked for confirmation of his expectation that everyone is in
          agreement that the
          <tt>std::codecvt&lt;charN_t, char8_t, std::mbstate_t&gt;</tt>
          specializations that should not have been added in the first place
          should be deprecated and removed.</li>
      <li>Victor replied with a thumbs up.</li>
      <li>Alisdair stated that the deprecated
          <tt>std::codecvt&lt;charN_t, char, std::mbstate_t&gt;</tt>
          specializations are only needed by implementors that want to support
          iostreams with the <tt>charN_t</tt> types.</li>
      <li>Tom agreed.</li>
      <li>Steve noted that those are specified with fixed UTF encodings.</li>
      <li>Jens stated that, as specified, those facets have the wrong
          semantics.</li>
      <li>Alisdair observed that the current semantics stand in the way of an
          implementor doing the right thing with iostreams of <tt>charN_t</tt>
          type.</li>
      <li>Jens agreed.</li>
      <li>Corentin claimed that there are two questions:
        <ul>
          <li>Whether we think <tt>std::codecvt</tt> is useful to users and
              whether we want to continue to support it in the standard.</li>
          <li>How iostreams perform conversions.</li>
        </ul>
      </li>
      <li>Corentin asserted that we don't have to rely on <tt>std::codecvt</tt>
          to implement conversions.</li>
      <li>Tom agreed, but noted that a new mechanism would presumably have to be
          applied only for the <tt>charN_t</tt> types so as not to interfere
          with iostreams of <tt>char</tt> and <tt>wchar_t</tt>.</li>
      <li>Steve stated that it isn't clear that the <tt>std::codecvt</tt> facets
          are doing what anyone wants.</li>
      <li>Tom observed that iostreams of <tt>wchar_t</tt> are pretty much only
          used on Windows and iostreams of <tt>char</tt> use a
          <tt>std::codecvt</tt> facet that does nothing by default.</li>
      <li>Alisdair requested that any proposed changes to the
          <tt>std::codecvt</tt> facets include discussion of how the virtual
          functions can be overridden to provide different behavior.</li>
      <li>Alisdair asked if any changes are required to P2873.</li>
      <li>Tom replied that he is leaning towards undeprecating those facets
          since the <tt>char8_t</tt> facets that were intended to replace them
          don't actually do so.</li>
      <li>Jens reiterated that the deprecated facets have the problem that they
          convert to the wrong encoding.</li>
      <li>Jens stated that, once removed, they could be reintroduced with new
          semantics.</li>
      <li>Tom replied that the facets have already been deprecated for two
          release cycles and that implementations diagnose them.</li>
      <li>Mark acknowledged the deprecation but pointed out that warnings are
          suppressed in system headers.</li>
      <li>Tom noted that warnings will have been generated for any explicit use
          of the deprecated specializations.</li>
      <li>Jens observed that the deprecation has only poisoned any existing
          <tt>charN_t</tt> iostream implementations and asserted that removing
          them is the clearest path forward.</li>
      <li>Jens claimed that removal sends a stonger message than deprecation for
          any existing uses.</li>
      <li>Corentin expressed support for removing them and then adding them
          again later if needed.</li>
      <li>Jens argued for focusing on cleanup in this release cycle rather than
          considering whether we want to add support for <tt>charN_t</tt> in
          iostreams.</li>
      <li>Tom turned discussion to the final issue; that the deprecated
          <tt>std::codecvt&lt;char16_t, char, std::mbstate_t&gt;</tt> facet
          doesn't satisfy the N:1 rule for <tt>std::basic_filebuf</tt>.</li>
      <li>Tom noted that the <tt>wchar_t</tt> specialization has this issue as
          well.</li>
      <li>Jens pointed out that it technically doesn't because the library does
          not permit UTF-16 for the wide encoding.</li>
      <li><em>[ Editor's note: see
          <a href="http://eel.is/c++draft/character.seq.general#1.2)">[character.seq.general]p(1,2)</a>.
          ]</em></li>
      <li>Jens asserted that we should not address this without a paper.</li>
      <li>Tom agreed.</li>
      <li>Hubert expressed his perception of where consensus is headed; that we
          are leaning towards a clean slate for a potential proposal to
          introduce iostreams of <tt>charN_t</tt>.</li>
      <li>Jens agreed.</li>
      <li>Tom interpreted that as an argument for Alisdair's paper going forward
          as is.</li>
      <li>Corentin stated that any paper that proposes iostreams for
          <tt>charN_t</tt> needs to explore use cases.</li>
      <li>Jens added that such a paper must also consider the current absence of
          <tt>std::codecvt&lt;char8_t, char, std::mbstate_t&gt;</tt>
          specializations.</li>
      <li>Tom agreed and argued that such specializations should not be added
          until there is a demonstrated need for them.</li>
      <li>Jens requested that Alisdair's paper clearly delineate what actions to
          take now vs what would be needed by a hypothetical proposal to
          introduce iostreams of <tt>charN_t</tt>.</li>
      <li>Alisdair stated he would like to update the rationale so as to better
          explain the situation to LEWG and then submit a revision for LWG for
          the post-Kona mailing.</li>
      <li>Steve suggested posting the revision to the SG16 mailing list for
          additional review.</li>
    </ul>
  </li>
  <li>Tom discussed scheduling for the next SG16 meeting:
    <ul>
      <li>Tom announced that the next regularly scheduled SG16 meeting would
          conflict with the WG21 meeting in Kona and that the one after that
          conflicts with Thanksgiving in the US.</li>
      <li>Tom suggested meeting on 2023-11-15 and 2023-12-06 and then pause
          until the new year.</li>
      <li>Jens objected that 2023-11-15 is too close to Kona post-meeting
          activities.</li>
      <li>Tom suggested meeting on 2023-12-06 and 2023-12-20.</li>
      <li>Victor stated he would not be available on 2023-12-20.</li>
      <li>Tom proposed that we meet 2023-12-06 and evaluate then whether to meet
          2023-12-20 or suspend until the new year.</li>
      <li><em>[ Editor's note: in later
          <a href="https://lists.isocpp.org/sg16/2023/10/3998.php">mailing list discussion</a>
          it was decided the group would meet again 2023-11-29 and 2023-12-13.
          ]</em></li>
    </ul>
  </li>
</ul>


<h1 id="2023_11_29">November 29th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2980r0">P2980R0: A motivation, scope, and plan for a physical quantities and units library</a>:
    <ul>
      <li>Support for a <tt>fixed_string</tt> type as referenced in the
          <a href="https://wg21.link/p2980r0#external-dependencies">"External dependencies" section</a>.</li>
      <li>Support for <tt>std::format</tt> and display of symbol names.</li>
      <li>Support for <tt>wchar_t</tt>, <tt>char8_t</tt>, <tt>char16_t</tt>,
          and <tt>char32_t</tt>.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Eddie Nolan</li>
  <li>Fraser Gordon</li>
  <li>Lauri Vasama</li>
  <li>Mateusz Pusz</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>A round of introductions was held for new attendee Lauri Vasama.</li>
  <li><a href="https://wg21.link/p2980r0">P2980R0: A motivation, scope, and plan for a physical quantities and units library</a>:
    <ul>
      <li>Mateusz explained that the contents of this paper, as well as the
          contents of
          <a href="https://wg21.link/p2981">P2981 (Improving our safety with a physical quantities and units library)</a>
          and
          <a href="https://wg21.link/p2982">P2982 (<tt>std::quantity</tt> as a numeric type)</a>
          are being merged into a new paper following feedback during the Kona
          2023 meeting.</li>
      <li>Mateusz proceded with presenting a draft version of the new paper.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p3045r0">P3045R0: Quantities and units library</a>:
    <ul>
      <li><em>[ Editor's note: D3045R0 was the active paper under discussion at
          the telecon.
          The agenda and links used here reference P3045R0 since the links to
          the draft paper were ephemeral.
          The published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>Mateusz introduced the paper:
        <ul>
          <li>Formatting support is needed to present dimensions and units.</li>
          <li>Unicode doesn't provide subscript and superscript characters for
              all Latin characters, so formatting necessarily differs from
              conventional notation in some cases.</li>
          <li>The design currently specifies symbol names in terms of
              <tt>char</tt> and assumes a Unicode encoding.</li>
          <li>A <tt>fixed_string</tt> type is required to enable a unit symbol
              to be passed as a template argument for the <tt>named_unit</tt>
              class template.</li>
          <li>The library only requires a <tt>fixed_string</tt> type with read
              capabilities; mutation is not needed.</li>
          <li>There are many implementations of a <tt>fixed_string</tt> type
              and re-inventing yet another one for this library is not
              desirable.</li>
          <li>There are many design options for a <tt>fixed_string</tt> type
              including whether mutate and resize operations are supported or
              whether the type can be implemented with <tt>std::string</tt> and
              a fixed allocator.</li>
          <li><tt>std::string_view</tt> does not support mutation.</li>
          <li>The conventional notation for SI units depends on characters that
              are not represented in ASCII or in the basic character set.</li>
          <li>Some users will require ASCII-only output and there is no standard
              specification for ASCII-only symbol names.</li>
          <li>Supporting both Unicode and non-Unicode formatting requires
              alternative symbols.</li>
          <li>The <tt>basic_symbol_text</tt> class template allows for both a
              Unicode and ASCII-only representation to be provided.</li>
        </ul>
      </li>
      <li>Tom mentioned that formatted output should be designed for
          roundtripping so that the output produced is amenable to
          scanning.</li>
      <li>Tom noted that a proposal for text parsing is making its way through
          the committee.</li>
      <li><em>[ Editor's note: See
          <a href="https://wg21.link/p1729">P1729 (Text Parsing)</a>.
          ]</em></li>
      <li>Mateusz agreed that roundtripping is important to support
          serialization to a text file and back.</li>
      <li>Tom suggested that, in lieu of a <tt>fixed_string</tt> type, string
          operations could be provided by layering <tt>std::string_view</tt> on
          top of a template parameter that provides contiguous storage.</li>
      <li>Mateusz agreed that <tt>std::array</tt> could be used.</li>
      <li>Tom acknowledged that <tt>std::array</tt> is a structural type and
          thus usable as a non-type template parameter.</li>
      <li>Eddie asked if <tt>operator+</tt> and other operators could be
          provided on top of <tt>std::array</tt>.</li>
      <li>Mateusz replied that he believed so.</li>
      <li>Lauri expressed concern that deduction guides might be problematic
          due to null terminators.</li>
      <li>Tom noted that the proposal assumes that a string literal is always
          passed as the template argument for symbol names.</li>
      <li>Lauri stated that the array approach won't work if there is special
          handling of string literals.</li>
      <li>Eddie suggested that a simple wrapper type with a <tt>std::array</tt>
          member and a suitable deduction guide could work.</li>
      <li>Tom suggested use of a UDL since they can only be used with a string
          literal.</li>
      <li>Mateusz replied that consideration should be given to this
          functionality being user facing.</li>
      <li>Steve stated that use of <tt>std::array</tt> instead of a more
          specific type could lead to ambiguities later.</li>
      <li>Lauri noted that a UDL would require another structural type.</li>
      <li>Tom agreed and acknowledged that use of a UDL would affect the
          interface and the user experience.</li>
      <li>Mateusz asserted that the parameter type should have associated text
          semantics and not just provide storage.</li>
      <li>Tom asked how important it is that the programmer be able to control
          whether symbols are formatted with Unicode or ASCII-only
          characters.</li>
      <li>Mateusz replied that there are some users that require ASCII-only
          output and that an inability to opt-out of a full Unicode mode would
          be a no-go.</li>
      <li>Mateusz stated that there isn't a similar concern for iostreams since
          a manipulator could be provided to control the mode.</li>
      <li>Tom stated this can remain an open question for now.</li>
      <li>Fraser suggested that the formatter could allow the programmer to
          specify an alternate unit symbol in the format specification
          itself.</li>
      <li>Victor noted that <tt>std::print</tt> works with iostreams, so
          iostream support could be provided indirectly.</li>
      <li>Victor asked if there are interactions with locale.</li>
      <li>Mateusz replied that the ability to provide locale support is limited
          by the standard not providing access to the Unicode CLDR database or
          similarly suitable locale support.</li>
      <li>Victor recommended reserving an 'L' option specifier in the format
          specification that would render the code ill-formed for now so as to
          allow extension later without an ABI break.</li>
      <li>Eddie noted that the standard already permits an implementation to
          choose between a Unicode and ASCII symbol for iostream formatting of
          <tt>std::chrono::duration</tt>.</li>
      <li><em>[ Editor's note: see
          <a href="http://eel.is/c++draft/time.duration.io#1.5">[time.duration.io]p(1,5)</a>:
          <blockquote class="quote">
            Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, it is
            implementation-defined whether <i>units-suffix</i> is
            "μs" ("\u00b5\u0073") or "us".
          </blockquote>
          ]</em></li>
      <li>Eddie opined that <tt>char8_t</tt> should probably be used for storage
          of the Unicode symbol name.</li>
      <li>Eddie asserted that the paper should substitute "basic character set"
          for "ASCII" throughout.</li>
      <li>Eddie noted that U+212B (ANGSTROM SIGN) has a tendency to get
          normalized to U+00C5 (LATIN CAPITAL LETTER A WITH RING ABOVE) or
          U+0041 (LATIN CAPITAL LETTER A) followed by
          U+030A (COMBINING RING ABOVE).</li>
      <li>Mateusz responded that, with regard to use of <tt>char8_t</tt>, that
          it was suggested to him to just use <tt>char</tt>.</li>
      <li>Tom replied that opinions differ on that.</li>
      <li>Steve asserted that the proposal should explicitly specify the code
          points to be used and should not rely on glyphs.</li>
      <li>Tom noted that the language specification has been updated to be
          explicit about code points, but that fewer such updates have been done
          for the library specification.</li>
      <li>Eddie asserted that normalization should be specified as well.</li>
      <li>Tom agreed and stated a preference for NFC.</li>
      <li>Eddie disagreed with the use of NFC since, per earlier discussion,
          U+212B (ANGSTROM SIGN) won't be preserved.</li>
      <li>Steve pointed out that, although the standard requires NFC for
          identifiers, it imposes no such requirement on string literals.</li>
      <li>After some back and forth it was pointed out that the precedent in the
          standard is that the code point used for iostream formatting of
          <tt>std::chrono::duration</tt> is U+00B5 (MICRO SIGN) rather than its
          normalized equivalent U+03BC (GREEK SMALL LETTER MU).</li>
      <li>Eddie opined that, given this precedent, we should not specify a
          normalization for units, and given multiple alternatives we should use
          code points corresponding to units, e.g. U+212B (ANGSTROM SIGN) rather
          than U+00C5 (LATIN CAPITAL LETTER A WITH RING ABOVE).</li>
      <li>Mateusz directed discussion to section 13.1.4.1
          (<tt>unit_symbol_formatting</tt>) where various enumerations are
          defined to support encapsolating formatting in the
          <tt>unit_symbol_formatting</tt> class.</li>
      <li>Victor commented that the enumeration types in that section should
          have specified underlying types unless they are intended to be
          transient.</li>
      <li>Mateusz replied that the enumerations are only used at compile-time,
          but agreed that adding a fixed underlying type might still make
          sense.</li>
      <li>Mateusz explained that <tt>space_before_unit_symbol</tt> is provided
          as a customization point to control whether a space is inserted
          between a value and its unit symbol by default.</li>
      <li>Mateusz directed discussion to section 13.2.3.1
          (<tt>std::format</tt> Grammar) and noted that the proposed grammar is
          similar to that for <tt>std::chrono</tt> with the addition of options
          for text encoding, and controls for inserting a solidus or separator
          character.</li>
      <li>Victor observed that the <tt>units-unit-modifier</tt> seems odd since,
          as specified, it requires that if any of <tt>units-text-encoding</tt>,
          <tt>units-unit-symbol-denominator</tt>, and
          <tt>units-unit-symbol-separator</tt> is present, then they all must
          be.</li>
      <li>Victor asked whether each of those terms should appear separately in
          square brackets.</li>
      <li>Mateusz replied that the intent is that each term can optionally be
          present in an unordered sequence.</li>
      <li>Tom replied that specifying an order would avoid having to consider
          each term being present multiple times.</li>
    </ul>
  </li>
  <li>Tom raised discussion of upcoming meeting plans:
    <ul>
      <li>Tom stated that the next meeting is scheduled for December 13th and
          that he would like to return to some LWG issues.</li>
      <li><em>[ Editor's note: The December 13th meeting was canceled due to
          lack of sufficient progress on the LWG issues to warrant additional
          discussion. ]</em></li>
      <li>Tom asked Mateusz if we can resume discussion of this paper on
          January 10th.</li>
      <li>Mateusz replied that he is not available that week.</li>
      <li>Tom asked if January 24th would work.</li>
      <li>Mateusz replied affirmatively.</li>
      <li>Mateusz requested a list of items to address or consider before the
          January 24th meeting so that he can work on them to try and get some
          implementation experience in the meantime.</li>
    </ul>
  </li>
</ul>


<h1 id="2024_01_10">January 10th, 2024</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>.</li>
  <li><a href="https://wg21.link/p2626r0">P2626R0: charN_t incremental adoption: Casting pointers of UTF character types</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Alisdair Meredith</li>
  <li>Corentin Jabot</li>
  <li>Eddie Nolan</li>
  <li>Fraser Gordon</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>Robin announced that the planned 2024-01-24 SG16 meeting overlaps with
      the UTC #178 meeting and that he will therefore be unable to attend.</li>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>:
    <ul>
      <li>Jens provided an introduction:
        <ul>
          <li>Undated references refer to the latest edition of such
              references.</li>
          <li>The ISO prefers undated references.</li>
          <li>WG21 negotiates the use of dated references with the ISO editors
              based on the fact that conscious effort is required to align
              wording and semantics with new editions.</li>
          <li>The C++23 draft is still undergoing editorial changes in
              conjunction with the ISO.</li>
          <li>The C++ standard used to have a normative reference to
              ISO/IEC 10646, but the reference was redirected to the
              Unicode Standard following additions that required features that
              are not specified in ISO/IEC 10646.</li>
          <li><em>[ Editor's note: The change of normative reference was made
              via
              <a href="https://wg21.link/p2736r2">P2736R2 (Referencing The Unicode Standard)</a>.
              ]</em></li>
          <li>ISO/IEC 10646 is not identical to the relevant portions of the
              Unicode standard.</li>
          <li>The ISO has so far not complained about the C++ standard's use of
              the Unicode Standard despite the ISO generally preferring to
              refer to ISO standards.</li>
          <li>The undated reference to the Unicode Standard is "live"; which
              means that, as soon as a new Unicode Standard is published, the
              reference automatically refers to that edition.</li>
          <li>That implies that a conforming implementation of C++23 that uses
              Unicode 15 becomes non-conforming the moment that Unicode 16 is
              published.</li>
          <li>Changes to Unicode algorithms could impose ABI breaks that create
              difficulties for implementors.</li>
          <li>The proposed resolution is to require conformance with
              Unicode 15.</li>
          <li>It has also been suggested that a minimum Unicode version be
              specified with an allowance for implementors to use a more recent
              version.</li>
          <li>A reference to a particular Unicode version is benficial even if
              an allowance is made for use of a later version.</li>
          <li>Specifying both an undated and a dated reference would be
              weird.</li>
        </ul>
      </li>
      <li>Alisdair stated that issuing a DR has a similar effect to publication
          of a new edition of an undated reference, but differs in that the
          change happens under the auspices of WG21 rather than being imposed
          by an unaffiliated third party.</li>
      <li>Jens clarified that DRs are not ISO publications and that WG21 so far
          has not made use of the ISO procedures for issuing technical
          corrigenda for defects or amendments for enhancements.</li>
      <li>Robin objected to the notion of the Unicode Consortium being an
          unaffiliated third party and noted the formal liaison relationship
          with SC22.</li>
      <li>Steve opined that fixing the Unicode version to Unicode 15 is
          probably fine for C++23.</li>
      <li>Jens replied that C++23 is done with the exception of editorial
          changes being coordinated with the ISO and that any action taken for
          this CWG issue will target C++26.</li>
      <li>Steve reported that he tends to start observing use of new Unicode
          features within four to six months of the publication of a new
          Unicode version.</li>
      <li>Steve stated that new emoji are often the first new feature observed
          and that such text needs to be correctly processed.</li>
      <li>Steve asserted that waiting for the next C++ standard for support of
          a new Unicode version isn't viable.</li>
      <li>Steve agreed with the approach of specifying a minimum version with
          an allowance for implementors to upgrade at their discretion.</li>
      <li>Steve advised against implementors using different Unicode versions
          for different C++ standard conformance modes since doing so would
          invite ODR violations.</li>
      <li>Corentin expressed agreement with Steve's comments.</li>
      <li>Corentin asserted that implementors need to be able to keep up with
          the Unicode Standard at a faster pace than the C++ standard can.</li>
      <li>Corentin stated that it is likely not viable to support different
          Unicode versions for different C++ standard conformance modes.</li>
      <li>Corentin reported having tried to support multiple Unicode versions
          in a private project and that it didn't work well.</li>
      <li>Corentin noted that the Unicode Standard has a good history of
          maintaining backward compatibility and that changes made often
          address defects for which fixes are desirable.</li>
      <li>Corentin agreed that a dated reference in the C++ standard is useful
          to facilitate references to specific sections by number and name.</li>
      <li>Corentin opined that guidance for implementors to handle or avoid ABI
          issues in accordance with Unicode stability policies would be
          useful.</li>
      <li>Corentin suggested that a note that expresses that intent would be
          helpful.</li>
      <li>Corentin reported that Clang releases have stayed current with the
          most recent Unicode versions and will continue to do so.</li>
      <li>Alisdair expressed alignment with Jonathan's suggestion for the
          version of the Unicode standard to be implementation-defined for
          defect reporting purposes.</li>
      <li>Alisdair stated a preference for not requiring a minimum version so
          that implementors can provide options to enable backward
          compatibility with previous releases while remaining conforming.</li>
      <li>Eddie noted an advantage of an undated reference is that it avoids
          potential opposition to updating the normative reference to a newer
          version due to ABI concerns.</li>
      <li>Eddie explained that <tt>std::format</tt> already has the potential
          to lock in at compile-time features from the Unicode Standard that
          don't have a stability policy.</li>
      <li><em>[ Editor's note: Eddie later
          <a href="https://lists.isocpp.org/sg16/2024/01/4097.php">clarified on the SG16 mailing list</a>
          some misconceptions regarding <tt>constexpr</tt> and
          <tt>std::format</tt>; implementors have flexibility to isolate ABI
          concerns using <tt>if constexpr</tt>. ]</em></li>
      <li>Eddie agreed that it would be a good idea to provide guidance to
          implementors regarding how to isolate ABI concerns.</li>
      <li>Robin recognized that, in the real world, modern compilers support
          C++11 despite C++11 no longer being an active ISO standard, and
          projects are still developed with it.</li>
      <li>Robin cautioned that, if the version of the Unicode standard is tied
          to the C++ standard version, then projects using an older C++ version
          could be using a 10+ year old Unicode version and that possibility is
          even more concerning than having to wait three years to use a newer
          version.</li>
      <li>Robin emphasized the Unicode Standard's stability guarantees.</li>
      <li>Robin noted that implementations of a Unicode algorithm impose a
          limit on what Unicode versions are compatible.</li>
      <li>Steve provided an example of such limitations;
          extended grapheme clusters (EGCs) were introduced after the initial
          Unicode release and the use of such features imposes a minimum
          version that is required.</li>
      <li>Robin noted in the chat that EGCs were introduced in Unicode 5.1 in
          April of 2008.</li>
      <li>Corentin expressed support for specifying a minimum Unicode version
          for portability reasons.</li>
      <li>Corentin stated that he is not concerned about ABI issues at this
          point and asserted they haven't been a practical issue for Unicode
          concerns so far.</li>
      <li>Mark replied that libc++ does have an ABI issue that will need to be
          resolved; there is a table that needs to have an ABI tag applied to
          it.</li>
      <li>Mark expressed support for implementations being able to use newer
          Unicode versions because that is useful for users.</li>
      <li>Mark stated a preference for an implementation-defined version rather
          than one which must be adhered to.</li>
      <li>Alisdair indicated that he would be content to have market pressures
          determine compatibility.</li>
      <li>Alisdair stated a desire for an allowance for a conforming
          implementation to support use of an older Unicode version for
          compatibility with prior C++ standard versions.</li>
      <li>Alisdair stated in chat:
          "Conversely, I would not object to a “recommended practice” to set
          the floor, rather than making it normative".</li>
      <li>Eddie asked if there is an ABI impact from <tt>std::format</tt> width
          estimation changes.</li>
      <li>Mark replied that the width estimation in libc++ is <tt>constexpr</tt>
          as an implementation detail.</li>
      <li>Tom expressed a belief that width estimation has to be performed with
          run-time field values.</li>
      <li>Corentin acknowledged that the C++ standard may need to refer to a
          minimum Unicode Standard version just to be able to refer to certain
          features.</li>
      <li>Corentin asserted that there are ways that implementors can hide
          things behind ABI and that this includes use in <tt>constexpr</tt>
          context.</li>
      <li>Jens agreed with Alisdair that the Unicode version actually used in a
          particular language mode should be implementation-defined.</li>
      <li>Jens disagreed about not specifying a definite minimum version.</li>
      <li>Jens explained that core language features like named universal
          characters (<tt>\N{...}</tt>) require a minimum Unicode version in
          order to write portable code.</li>
      <li>Jens asserted that features that can't be reliably used across
          implementations should be removed.</li>
      <li>Jens observed that a consistent version of the Unicode Standard is
          required in order for the C++ standard to be consistent.</li>
      <li>Jens opined that the C++ standard should not reference different
          Unicode versions for the core language and the standard library.</li>
      <li>Tom asked if it might make sense for the minimum Unicode Standard
          version required for implementations to conform to the C++ standard to
          be different from the normative dated reference.</li>
      <li>Jens replied negatively.</li>
      <li>Jens stated that the formal text needs to provide the right guarantees
          even if implementors all do what we consider to be the right thing;
          the formal text must be sufficient to write portable programs.</li>
      <li>Jens noted that the ISO will not permit the introduction of an alias
          for a normative reference.</li>
      <li>Jens expressed uncertainty where a Unicode version conformance
          requirement should be specified, but stated that is likely a solvable
          problem.</li>
      <li>Jens observed that identifiers have a forward compatibility guarantee
          thanks to the Unicode Standard stability policies for XID start and
          continue properties.</li>
      <li>Steve reported that his organization builds their internal toolchain
          using system supplied libraries and noted this could produce a
          non-conforming implementation due to building with older Unicode
          libraries.</li>
      <li>Steve indicated he is ok with that result though.</li>
      <li>Steve noted that the Unicode Standard is a coherent specification and
          that mixing parts from different versions of it can produce
          non-sensical results.</li>
      <li>Steve described "ABI problems" as shorthand for lots of different
          problems, some of which, like virtual function table layout
          differences, are catastrophic while other cases, like fast math
          enabled vs disabled, are not.</li>
      <li>Alisdair stated that he has been persuaded by Jens' arguments that a
          dated reference to the Unicode Standard in the C++ standard with the
          actual version being implementation-defined is a good direction.</li>
      <li>Alisdair opined that it is still important for implementors to be
          able to provide backwards compatibility and that he would prefer
          normative guidance for use of the normative dated reference to be the
          minimal version supported by an implementation.</li>
      <li>Gordon explained that the ISO prefers undated references because ISO
          standard editions effectively disappear when superceded and asked for
          clarification that the Unicode Consortium handles this
          differently.</li>
      <li>Robin confirmed that release of a new Unicode Standard does not
          obviate the preceding ones and provided a link to
          <a href="https://www.unicode.org/versions">https://www.unicode.org/versions</a>
          in the chat.</li>
      <li>Robin asked for Jens to confirm that, with regard to named universal
          characters, whether the concern is in regard to upgrading
          compilers.</li>
      <li>Jens explained that implementations might want to issue a portability
          warning for use of a name that was added in a later Unicode Standard
          than the dated version from the C++ Standard.</li>
      <li>Jens reported that he wants to be able to rely on all character names
          from, e.g., Unicode 15, being available for use across all C++
          implementations.</li>
      <li>Robin asked if the same concern applies to identifiers.</li>
      <li>Jens confirmed that it does.</li>
      <li>Robin explained that, as long as the C++ standard specifies a minimum
          version and that implementations are permitted to use a newer version,
          then he is content; he would not be content with the C++ standard
          specifying a maximum version though.</li>
      <li>Steve noted that implementations are free to accept ill-formed code as
          long as a diagnostic is issued.</li>
      <li>Alisdair asked whether a feature test macro with predictable values
          can be specified.</li>
      <li>Jens noted that the C++ standard currently provides the
          <tt>__STDC_ISO_10646__</tt> macro with a date value.</li>
      <li>Corentin replied that the existing macro can't be relied on at
          compile-time because it is shared between the core language and the
          standard library.</li>
      <li>Robin reported that the Unicode Standard does not have a stability
          policy for the format of the Unicode version but stated that such a
          policy could be proposed.</li>
      <li>Jens replied that the year and month of the release date suffices
          assuming the Unicode Consortium doesn't start shipping new releases
          at a rate higher than once a month.</li>
      <li>Tom summarized his perception of the emerging consensus:
        <ul>
          <li>The C++ standard should have a single dated reference to the
              Unicode Standard for consistency purposes.</li>
          <li>A minimum Unicode version should be specified as normative
              guidance or as a mandatory requirement.</li>
          <li>The actual Unicode version in use by an implementation should be
              implementation-defined and allowed to be newer than the minimum
              version.</li>
          <li>The Unicode version in use by an implementation may differ for
              the core language vs the standard library; separate feature test
              macros may be required to identify the implementation-defined
              version.</li>
        </ul>
      </li>
      <li>Jens noted that the minimum version may be increased in future C++
          standards to accommodate references to features introduced in newer
          versions.</li>
      <li>Tom observed that some effort will be required to identify the
          minimum Unicode version required for the C++ standard.</li>
      <li>Suggestions were made to specify Unicode 15 as the minimum
          version.</li>
      <li><b>Poll 1: Recommend having a dated reference to Unicode in the
          "Normative references" and add permission to implement an
          implementation-defined version.</b>
        <ul>
          <li><b>Attendees: 10</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
      <li><b>Poll 2: The standard shall specify a mandatory minimum Unicode
          version.</b>
        <ul>
          <li><b>Attendees: 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">3</th>
                <th style="text-align:right">5</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Consensus in favor</b></li>
          <li><b>A: I would prefer to allow implementations to use older
              Unicode versions and still be considered conforming;
              implementations will do so regardless.</b></li>
        </ul>
      </li>
      <li>Steve summarized the consensus: we recommend having a dated reference
          to the Unicode Standard in the "Normative references" section, a
          minimum version requirement, and an allowance for implementors to use
          an implementation-defined later version.</li>
      <li>Jens stated that he will update the proposed resolution for the CWG
          issue to reflect the SG16 consensus.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2626r0">P2626R0: charN_t incremental adoption: Casting pointers of UTF character types</a>:
    <ul>
      <li>Tom thanked Corentin for agreeing to defer discussion of this
          paper.</li>
    </ul>
  </li>
  <li>Tom reported that the next meeting will be in two weeks and will continue
      review of Mateusz' paper as well as additional followup on the CWG
      issue.</li>
</ul>


<h1 id="2024_01_24">January 24th, 2024</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p3045r0">P3045R0: Quantities and units library</a>.</li>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Billy Baker</li>
  <li>Corentin Jabot</li>
  <li>Eddie Nolan</li>
  <li>Elias Kosunen</li>
  <li>Fraser Gordon</li>
  <li>Lauri Vasama</li>
  <li>Mark de Wever</li>
  <li>Mateusz Pusz</li>
  <li>Nathan Owen</li>
  <li>Jens Maurer</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p3045r0">P3045R0: Quantities and units library</a>:
    <ul>
      <li>Mateusz provided an introduction:
        <ul>
          <li>There is a need for some unit types to have both a basic unit
              symbol and one that includes characters that are not in the basic
              literal character set.</li>
          <li>The proposed design allows specifying multiple symbols.</li>
          <li>We need to decide how these different symbols are specified.</li>
        </ul>
      </li>
      <li>Tom asked what character types need to be supported.</li>
      <li>Corentin recalled an LWG issue concerning the symbol used to print
          <tt>std::chrono::duration</tt> values with a microseconds period and
          that the issue was resolved in favor of allowing the implementation to
          choose between two symbols.</li>
      <li><em>[ Editor's note: See
          <a href="https://wg21.link/lwg3094">LWG #3094 (§[time.duration.io]p4 makes surprising claims about encoding)</a>
          and the current wording in
          <a href="http://eel.is/c++draft/time.duration.io#1.5">[time.duration.io]p(1.5)</a>.
          ]</em></li>
      <li>Corentin suggested that precedent could be followed here.</li>
      <li>Corentin opined that there is not much motivation for
          <tt>wchar_t</tt>, <tt>char16_t</tt>, and <tt>char32_t</tt>.</li>
      <li>Mateusz responded that there was only one such case to be addressed
          for the chrono library but there are many such cases for the units
          library.</li>
      <li>Mateusz added that there is a desire to allow programmers to restrict
          formatting to basic characters so as to avoid non-basic characters
          being written in some cases.</li>
      <li>Mateusz acknowledged that removing the need for multiple symbols would
          simplify the design.</li>
      <li>Victor agreed with Corentin and argued for a design that is simple and
          prioritizes Unicode.</li>
      <li>Victor stated it should not be necessary to spell out symbols for all
          five encodings.</li>
      <li>Victor concurred that the <tt>std::chrono::duration</tt> example is a
          good model to follow.</li>
      <li>Tom expressed skepticism regarding an implementation-defined approach
          since the units library is designed to be user extensible.</li>
      <li>Tom expressed a preference to specify a design that will work for
          user code.</li>
      <li>Corentin replied that the symbols for the unit types defined by the
          standard library could be implementation-defined.</li>
      <li>Corentin observed that passing arbitrary string literals as template
          arguments could cause compatibility issues if a program includes
          translation units built with different choices of the ordinary
          literal encoding.</li>
      <li>Corentin shared
          <a href="https://godbolt.org/z/8frTvfvoE">https://godbolt.org/z/8frTvfvoE</a>
          as an example that demonstrates the concern.</li>
      <li><em>[ Editor's note: The concern is that a string literal like
          <tt>"µ"</tt> might be differently encoded such that the specialization
          <tt>prefixed_unit&lt;{"µ", "u"}, ...&gt;</tt> might not coincide
          across translation units. ]</em></li>
      <li>Corentin expressed uncertainty regarding catering to programmers that
          want to avoid seeing non-ASCII characters.</li>
      <li>Mateusz replied that the concern isn't just for reading the formatted
          output but that people need to be able to write the characters as
          well.</li>
      <li>Mateusz reported that there is no standard for ASCII-only symbol
          names.</li>
      <li>Steve agreed that the choice of ordinary literal encoding can create
          portability problems.</li>
      <li>Steve advised caution regarding potentially requiring the ordinary
          literal encoding to be able to accommodate characters not in the
          basic literal encoding.</li>
      <li>Elias observed that specifying the symbols as implementation-defined
          would cause problems for exchange of text.</li>
      <li>Steve noted that C++23 requires a conforming implementation to
          support UTF-8.</li>
      <li>Tom agreed, but noted that the UTF-8 requirement is for the encoding
          of source files and that the ordinary literal encoding need not
          support UTF-8.</li>
      <li>Steve observed that the proposed design would therefore be
          unimplementable for some implementors.</li>
      <li>Mark opined that it would be useful to specify alternate symbols for
          implementations to use.</li>
      <li>Corentin asserted that ordinary character and string literals can't
          be used as template arguments due to the possibility of inconsistent
          ordinary literal encoding.</li>
      <li>Mateusz pondered whether a Unicode encoding should be used for all
          the symbols.</li>
      <li>Corentin replied that he thinks that is necessary to avoid
          compatibility problems.</li>
      <li>Steve observed that the compiler can't correct for such
          incompatibilities because this is effectively a linkage concern.</li>
      <li>Elias asked if there is a compelling reason for the symbol names to
          be provided as template arguments.</li>
      <li>Mark replied that the motivation is to enable a succinct programming
          style as opposed to specializing a trait.</li>
      <li>Victor opined that the symbol is data and should not be specified as
          part of the type.</li>
      <li>Victor argued that moving the symbol out of the type system would
          make the design less fragile.</li>
      <li>Victor stated that macros can be used to provide a succinct
          programming style.</li>
      <li>Steve raised a concern that making data part of the type can lead to
          accidental ABI freezes where, for example, misspellings can't be
          fixed.</li>
      <li>Steve noted that such a design limits future extension possibilities
          as well.</li>
      <li>Tom asked Mateusz how moving the symbols out of template arguments
          would impact the design.</li>
      <li>Mateusz replied that users appreciate the terseness the current
          design allows and stated that exposing macros as part of a standard
          interface would not be desired.</li>
      <li>Mateusz acknowledged such a change would be possible though.</li>
      <li>Elias cautioned that we don't have an alternative design in front of
          us to consider and that makes it difficult to evaluate relative
          benefits.</li>
      <li>Mateusz stated that strong types are important to the design.</li>
      <li>Mateusz suggested A CRTP-based design could work.</li>
      <li>Victor stated that it seems problematic to have the symbol text be
          part of the identity of the type.</li>
      <li>Victor suggested that tag types would be more appropriate.</li>
      <li>Mateusz reported that he ran into difficulties when considering tag
          types but that he needs to explore some more.</li>
      <li>Mateusz stated that use of tag types would change the interface
          considerably.</li>
      <li>Steve returned discussion to support of multiple encodings and
          asserted that use of transliteration should be avoided since it can
          produce surprises like "Ω" (U+03A9 GREEK CAPITAL LETTER OMEGA)
          getting converted to "O".</li>
      <li>Tom summarized his impression of where the discussion has been
          leading:
        <ul>
          <li>The proposal authors should explore alternatives to passing
              symbols as template arguments.</li>
          <li>There does appear to be a need to specify symbol alternatives
              for different encodings.</li>
          <li>A method of specifying a symbol alternative in a UTF form and
              another as an ordinary string literal should suffice to support
              all five encodings.</li>
        </ul>
      </li>
      <li>Victor reiterated that exploration of alternative designs should
          include the option of implementation-defined symbol selection.</li>
      <li>Tom replied that there is still a need to specify symbol selection
          for user-defined units.</li>
      <li>Corentin agreed that there appears to be consensus for a fallback
          symbol to be used when the preferred symbol is not representable.</li>
      <li>Corentin expressed uncertainty regarding consensus for a user opt-in
          to use of a fallback symbol.</li>
      <li>Mateusz directed discussion toward use of '_' to indicate a
          subscripted character in cases where Unicode lacks a corresponding
          character.</li>
      <li>Steve stated that subscripted characters in Unicode exist solely for
          compatibility with legacy character sets and that subscripting and
          superscripting are considered markup.</li>
      <li>Corentin opined that if subscripting and superscripting can't be done
          uniformly everywhere, then it should not be done anywhere.</li>
      <li>Corentin suggested consulting with Robin.</li>
      <li>Corentin wondered whether the ISO standards on units suggest a
          solution.</li>
      <li>Jens stated that he doesn't think there is a portable way to
          represent physics symbols in ordinary string literals.</li>
      <li>Jens suggested that it should be possible to allow a user to insert
          markup for support of subscripting and superscripting.</li>
      <li>Jens questioned whether support for non-ASCII characters should be
          provided at all since plain text can't represent the desired
          formatting.</li>
      <li>Mateusz replied that others have provided similar feedback such as
          the ability to produce LaTeX.</li>
      <li>Mateusz stated that he doesn't know how to do that with
          <tt>std::format</tt> or <tt>std::print</tt> though.</li>
      <li>Corentin agreed with Jens that users will want more capabilities and
          that these symbols are intended for display in a terminal.</li>
      <li>Steve suggested that, since the library is intended to support
          user-defined units, perhaps the unit symbols defined by the standard
          library should be restricted to the basic literal character set and
          programmers can use whatever characters from the actual ordinary
          literal encoding that they like for their own unit types.</li>
      <li>Steve commented that the symbol is significant in the type
          system.</li>
      <li>Jens agreed that it is and that units need to be preserved such that
          <tt>2*speed_of_light == speed_of_light</tt>.</li>
      <li>Victor agreed with Jens that we shouldn't put too much effort into
          pretty formatting since users can perform their own formatting.</li>
      <li>Victor asserted that the main purpose of the library is to provide
          the unit primitives as opposed to nicely formatted output.</li>
      <li>Mateusz asked if <tt>std::format</tt> could potentially take a tag
          type to differentiate behavior.</li>
      <li>Victor replied that the way to differentiate behavior would be to
          write separate formatters.</li>
      <li>Jens noted that the way to opt-in to such differentiated behavior
          is to wrap types accordingly.</li>
      <li>Jens suggested updating the narrative of the paper to demonstrate how
          to produce nicely formatted output for these types.</li>
      <li>Jens indicated that it would be nice to be able to specify custom
          formatting with a terse syntax.</li>
      <li>Mateusz expressed uncertainty regarding how, for example, a
          <tt>std::vector</tt> of these types could be formatted in a custom
          way.</li>
      <li>Jens acknowledged uncertainty regarding whether the
          <tt>std::vector</tt> formatters could handle that.</li>
      <li>Jens observed that a <tt>std::vector</tt> wrapper could presumably
          apply a corresponding wrapper to its elements.</li>
      <li>Jens suggested that an inability to do so might imply a deficiency
          in <tt>std::format</tt> that might be worth addressing and stated
          that an HTML formatter shouldn't require reinventing
          <tt>std::format</tt>.</li>
      <li>Eddie opined that, even if formatted symbols are only used for
          debug-like scenarios, Unicode support is useful and should be a
          goal.</li>
      <li>Mateusz reported that none of the units libraries that he is aware
          of provide such extensive formatting capabilities.</li>
      <li>Jens opined that such capabilities are not needed for the standard
          either but that it would be useful to illustrate what a solution
          might look like.</li>
      <li>Steve asked for additional topics that would benefit from
          discussion.</li>
      <li>Mateusz asked for preferences regarding the return type of
          <tt>unit_symbol()</tt>.</li>
      <li>No opinions were offered.</li>
      <li>Mateusz stated that adding additional iostream manipulators is
          probably not desireable and recalled that previous discussion
          settled on just providing <tt>std::format</tt> support.</li>
      <li>Tom asked Victor if there is an SG16 concern regarding section
          13.4.1, "Controlling width, fill, and alignment".</li>
      <li>Victor replied that the behavior should be consistent with other
          formatters and that any reason to deviate should be discussed.</li>
      <li>Jens asked for confirmation that nested formatting works with
          ranges.</li>
      <li>Mark and Victor both confirmed.</li>
      <li>Mateusz stated that the proposal uses nested <tt>{}</tt> braces for
          formatting of subentities.</li>
      <li>Victor expressed opposition to use of <tt>{}</tt> for nesting
          because it closes off syntax space that could be used for other
          extentions.</li>
      <li>Victor noted that there are other delimiters that can be used.</li>
      <li>Mateusz stated that the parse context isn't copyable, so there
          isn't a portable way to handle nesting.</li>
      <li>Victor replied that implementation is straight forward using
          implementation internals.</li>
      <li>Jens noted that, for the purposes of standardization, it doesn't
          matter if the subentity selection is portably implementable using
          existing implementations.</li>
      <li>Corentin stated that the proposed approach doesn't support
          localization.</li>
      <li>Tom noted that message formatting capabilities would be required
          for that.</li>
    </ul>
  </li>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>:
    <ul>
      <li>Tom apologized for the lack of time for further review of this
          issue.</li>
    </ul>
  </li>
  <li>Tom announced that the next meeting will be 2024-02-07.</li>
</ul>


<h1 id="2024_02_07">February 7th, 2024</h1>

<h2>Draft agenda:</h2>

<ul>
  <li>Updates from the Unicode liaison from the UTC #178 meeting.</li>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>.</li>
  <li><a href="https://wg21.link/p2845r6">P2845R6: Formatting of std::filesystem::path</a>.</li>
  <li><a href="https://wg21.link/p3070r0">P3070R0: Formatting enums</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Eddie Nolan</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Nathan Owen</li>
  <li>Peter Bindels</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>Updates from the Unicode liaison from the UTC #178 meeting:
    <ul>
      <li>Robin shared the following updates:
        <ul>
          <li>Draft meeting minutes are available at
              <a href="https://www.unicode.org/L2/L2024/24006.htm#178-0">https://www.unicode.org/L2/L2024/24006.htm#178-0</a>.</li>
          <li>Character assignments may now be specified on a provisional basis
              to facilitate early feedback and development; this is particularly
              useful for font development.</li>
          <li>ICU will not expose characters in alpha or beta status.</li>
          <li>Product releases should not include support for provisional
              character assignments.</li>
          <li>Alpha review for Unicode 16.0 started yesterday; background
              material is available at
              <a href="https://www.unicode.org/review/pri497/pri497-background.html">https://www.unicode.org/review/pri497/pri497-background.html</a>.</li>
          <li>Unicode 16.0 will specify new normalization behavior that might
              invalidate optimization techniques used by some
              implementations.</li>
          <li>A conformance testsuite is available that exercises the new
              normalization behavior.</li>
          <li>There was a minor update to
              <a href="http://www.unicode.org/reports/tr55/">UTS #55</a>
              for case insensitive identifiers.</li>
          <li><em>[ Editor's note: See the changes to
              <a href="https://www.unicode.org/reports/tr55/tr55-4.html#Normalization-Case">section 3.1.1, "Normalization and Case", in the 2024-01-03 proposed update of UTS #55</a>.
              ]</em></li>
          <li>Fraser Gordon was nominated and confirmed to chair the
              Terminal Text Working Group.</li>
          <li>The ICU technical committee has created a new
              Inflection Working Group.</li>
        </ul>
      </li>
      <li>Tom noted that the new Inflection WG would presumably be relevant to
          the Message Formatting Working Group.</li>
      <li>Robin agreed.</li>
    </ul>
  </li>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>:
    <ul>
      <li>Tom explained that, following decisions made during the
          <a href="https://github.com/sg16-unicode/sg16-meetings#january-10th-2024">2024-01-10 SG16 meeting</a>,
          we now need to select a Unicode version for the standard to refer
          to.</li>
      <li>Steve proposed using the version that was current when designs were
          being evaluated and wording drafted.</li>
      <li>Steve observed that doing otherwise might result in references that
          don't exist in the normatively referenced version or that behavior or
          features might have changed.</li>
      <li>Steve stated that, for most features adopted during the C++23
          development cycle, that would probably be Unicode 15.</li>
      <li>Robin reported that Unicode 15.1.0 has material differences due to
          changes inspired by SG16 and the
          <a href="https://www.unicode.org/reports/tr55/">UTS #55 (Unicode Source Code Handling)</a>
          effort that impacted the <tt>XID_start</tt> and <tt>XID_continue</tt>
          properties.</li>
      <li>Robin noted that Unicode 15.1.0 also has changes for EGC segmentation
          for Indic scripts, shared a link to the
          <a href="https://www.unicode.org/reports/tr29/#Table_Sample_Grapheme_Clusters">Sample Grapheme Clusters table in UAX #29 (Unicode Text Segmentation)</a>,
          and referenced the Devanagari <i>kshi</i> example (क्षि).</li>
      <li>Robin observed that the current undated reference currently resolves
          to Unicode 15.1.0.</li>
      <li>Eddie indicated a desire to ensure that implementors can defer to ICU
          for normalization and be free to choose which ICU version they
          use.</li>
      <li>Eddie reported that, following discussion with Zach, he was convinced
          to use the latest Unicode version which is currently 15.1.0.</li>
      <li>Eddie stated that implementors should be able to use different Unicode
          versions for the core language and the standard library.</li>
      <li>Steve pointed out that there are multiple options for an ICU version
          to defer to; if they choose to defer to one supplied by the platform,
          then they could get stuck with an old version.</li>
      <li>Eddie replied that is motivation for implementors not to defer to a
          platform supplied version or for granting permission for use of an
          older version.</li>
      <li>Steve noted that Linux distributors like RedHat support the
          installation of new compiler versions on older OS releases.</li>
      <li>Steve reported having encountered issues due to use of old versions
          of some platform supplied libraries.</li>
      <li>Steve stated that we need to allow time for implementors to adapt to
          changes to the normatively referenced version.</li>
      <li>Tom asked Jens if he will want EWG to review the choice of normative
          Unicode version reference.</li>
      <li>Jens replied that this issue has wide visibility and that the related
          GitHub issue is tagged for EWG and LWG as well as SG16.</li>
      <li>Jens added that LWG can forward any concerns they have to LEWG.</li>
      <li>Jens stated that CWG will only be involved to vet the actual wording
          changes and the guarantees regarding availability of character names
          as needed for the core language.</li>
      <li>Mark commented that, if libc++ were to start relying on ICU, that such
          reliance would likely be expected to be satisfied by a distibution
          provided by the target platform.</li>
      <li>Mark stated that use of ICU would likely be determined on a
          per-feature basis.</li>
      <li>Eddie argued that such expectations suggest standardizing the lowest
          version that still covers everything in the standard.</li>
      <li>Jens noted that, at present, that lowest version is the most recent
          Unicode version due to the undated reference in C++23.</li>
      <li>Jens expressed being comfortable with specifying Unicode 15.0.</li>
      <li>Jens stated an expectation that implementors will likely honor the
          resolution of this CWG issue for C++23 if it is approved as a DR.</li>
      <li>Jens suggested that some implementors might choose to warn on use of
          features from newer Unicode versions.</li>
      <li>Robin reported that it is possible to subdivide ICU to include only
          necessary components.</li>
      <li>Robin added that it shouldn't be assumed that an implementor needs to
          rely on a version distributed with the platform.</li>
      <li>Steve stated that ICU has support for symbol versioning and that this
          would allow an implementor to distribute their own version such that
          it will not conflict with other versions.</li>
      <li>Jens suggested that future paper authors be encouraged to comment on
          whether implementations should or should not rely on ICU for
          particular features and the potential to get stuck with a dependency
          on an older version.</li>
      <li>Jens advocated for collecting opinions from implementors.</li>
      <li>Robin asserted that specifying Unicode 15.1.0 will help to position
          implementors for future upgrades.</li>
      <li>Steve claimed it would be useful to give implementors advanced
          notice.</li>
      <li>Tom asked if anyone knows what ICU version Microsoft provides and
          whether any implementations defer to it today.</li>
      <li>Mark reported that Microsoft relies on the platform ICU version for
          timezone data, but not for <tt>std::format()</tt> related
          features.</li>
      <li><em>[ Editor's note:
          <a href="https://learn.microsoft.com/en-us/windows/win32/intl/international-components-for-unicode--icu-">Microsoft's ICU documentation</a>
          does not report an ICU version, but does indicate that only C APIs are
          exposed due to the lack of a stable ABI for C++. ]</em></li>
      <li>Steve asserted that we should not use a normative reference for a
          version prior to Unicode 14.0.</li>
      <li>Steve stated that wording review would be necessary to determine if
          Unicode 13.0 matches the required features and intended semantics for
          recently adopted papers.</li>
      <li>Eddie asked whether SG16 would be ok if, for
          <a href="https://wg21.link/p2729">P2729 (Unicode in the Library, Part 2: Normalization)</a>,
          implementors wanted to use the version of ICU provided by the
          platform.</li>
      <li>Tom replied that he thinks implementors have options available to them
          to meet requirements; they might not love any of the options, but they
          do exist.</li>
      <li>Steve asserted that we need to make it clear to implementors that they
          must use consistent implementations of the Unicode algorithms.</li>
      <li>Eddie agreed and disclosed that there is also an unpublished proposal
          for segmentation.</li>
      <li>Eddie reported that there is a long history of security
          vulnerabilities that occured due to use of parsers that interpreted
          the same text inconsistently.</li>
      <li>Robin informed the group that ICU does not provide default tailoring
          support.</li>
      <li>Steve responded that the base tailoring algorithms are not terribly
          difficult to implement but that some data is required.</li>
      <li><b>Poll 1: Recommend specifying Unicode 15.1.0 as the minimum Unicode version for C++23 (as a DR) and C++26.</b>
        <ul>
          <li><b>Attendees: 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">5</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 in favor</b></li>
        </ul>
      </li>
      <li>Tom stated that, with regard to Unicode versions being consistent
          across the core language implementation and the standard library,
          that it doesn't seem feasible to not allow divergence.</li>
      <li>Steve commented that problems caused by a mismatch are unlikely to be
          worse than processing text from other sources.</li>
      <li>Eddie noted that it is common to use Clang with libstdc++ and libc++
          and that EDG does not provide a standard library implementation.</li>
      <li>Mark reported that different people tend to work on the compiler and
          the standard library and that the versions of each can be mixed;
          requiring a consistent Unicode version would be very hard.</li>
      <li>Steve took a devil's advocate role and suggested that, perhaps such
          cases are just not conforming.</li>
      <li>Steve stated that it is not required for all deployments to be
          conforming; non-conforming is not the same as useless.</li>
      <li>Steve opined that the standard should still acknowledge the
          possibility of mismatched versions.</li>
      <li>Robin noted that the standard library does not currently require a
          normative reference to Unicode for any of its features at the
          moment.</li>
      <li>Jens expressed a preference for treating the C++ standard as a unit
          and only normatively require a single Unicode version with allowances
          for use of a later version.</li>
      <li>Tom agreed, but stated a desire to provide programmers the ability to
          query the version in use.</li>
      <li>Jens replied that preprocessor behavior is impacted by Unicode
          version and that it is therefore unclear how useful a feature test
          macro would be.</li>
      <li>Steve suggested that we might be getting ahead of ourselves in asking
          what we would use a feature test macro for.</li>
      <li>Jens posited that a library version query utility of some kind might
          be more useful than a feature test macro.</li>
      <li>Jens stated that certain features can just be avoided for core
          language.</li>
      <li>Jens opined that it could be useful to write a <tt>#error</tt>
          directive based on Unicode version.</li>
      <li>Tom concluded that we should avoid specifying a feature test macro
          and an explicit allowance for the core language and standard library
          to use different Unicode versions until more need is identified.</li>
      <li>Tom stated that he will forward the CWG issue with the above poll.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2845r6">P2845R6: Formatting of std::filesystem::path</a>:
    <ul>
      <li>Victor introduced the recent changes.</li>
        <ul>
          <li>The <tt>path-format-spec</tt> now supports a <tt>g</tt> option to
              enable formatting a path as a generic path.</li>
        </ul>
      </li>
      <li>Discussion in chat confirmed that <tt>/</tt> is used as the path
          separator when formatting a generic path and that the native path
          separator is used otherwise.</li>
      <li><b>Poll 2: Forward P2845R6 to LEWG.</b>
        <ul>
          <li><b>Attendees: 9</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p3070r0">P3070R0: Formatting enums</a>:
    <ul>
      <li>Victor explained the motivation for the new feature:</li>
        <ul>
          <li>This allows defining a <tt>format_as()</tt> function rather than
              writing a <tt>std::formatter</tt> specialization.</li>
          <li>This approach is simpler and more efficient at run-time.</li>
        </ul>
      </li>
      <li>Jens asked if an alternate type presentation can be requested in the
          format specifier.</li>
      <li>Victor replied that a <tt>std::formatter</tt> specialization is
          required to do that.</li>
      <li>Tom asked if the format specifier has to be <tt>{}</tt>.</li>
      <li>Victor replied that it doesn't, that the format specifier is parsed
          according to the mapped type; the type returned by the
          <tt>format_as()</tt> customization point.</li>
      <li>Jens asked if <tt>format_as</tt> is an existing customization
          point.</li>
      <li>Victor replied that it is not; it is new with this proposal.</li>
      <li>Eddie observed that the proposed functionality seems useful for many
          types, but that the proposal is restricted to enumeration types.</li>
      <li>Victor responded that it is extensible to other types, but is limited
          to enumeration types for now due to lack of experience with other
          types.</li>
      <li>Mark asked how field widths are handled.</li>
      <li>Victor replied that they are handled the same as for the mapped
          type.</li>
      <li>Eddie asked for confirmation that, as proposed, an attempt to use
          this feature for a type other than an enumeration type will fail.</li>
      <li>Victor confirmed the intent, but noted that the proposed wording is
          currently missing a constraint.</li>
      <li>Jens asked if the mapping is applied recursively and what happens if
          <tt>as_format()</tt> returns another enumeration type.</li>
      <li>Victor replied that it should work, but that he needs to check and
          then update the paper accordingly.</li>
      <li>Peter observed that this approach doesn't solve the problem of
          wanting to format the name of an enumerator.</li>
      <li>Victor agreed that mapping an enumerator value to a name still has to
          be explicitly written but that reflection would make that easy.</li>
      <li><b>Poll 3: Forward P3070R0 to LEWG.</b>
        <ul>
          <li><b>Attendees: 9</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li>Tom announced that the next meeting will be on 2024-07-21 and that the
      agenda is TBD.</li>
</ul>


<h1 id="2024_02_21">February 21st, 2024</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>.
    <ul>
      <li>Identify updates needed for UAX #31 changes in Unicode 15.1.0.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg4043">LWG 4043: <tt>"ASCII"</tt> is not a registered character encoding</a>.</li>
  <li><a href="https://wg21.link/lwg4044">LWG 4044: Confusing requirements for <tt>std::print</tt> on POSIX platforms</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Eddie Nolan</li>
  <li>Fraser Gordon</li>
  <li>Jens Maurer</li>
  <li>Nathan Owens</li>
  <li>Peter Bindels</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://cplusplus.github.io/CWG/issues/2843.html">CWG 2843: Undated reference to Unicode makes C++ a moving target</a>:
    <ul>
      <li>Tom provided a brief introduction:
        <ul>
          <li>Unicode 15.1.0 introduced changes to
              <a href="https://www.unicode.org/reports/tr31/#Default_Identifier_Syntax">default identifier syntax</a>
              to allow U+200C (ZERO WIDTH NON-JOINER) and
              U+200D (ZERO WIDTH JOINER) in identifiers.</li>
          <li>We can choose to accept these changes or to adopt a profile that
              retains the prior behavior.</li>
          <li>Regardless, the removal of
              <a href="https://www.unicode.org/reports/tr31/#R1a">UAX31-R1a</a>
              necessitates an update to
              <a href="http://eel.is/c++draft/uaxid.def.rfmt">[uaxid.def.rfmt]</a>
              in
              <a href="http://eel.is/c++draft/uaxid">Annex E</a>.</li>
        </ul>
      </li>
      <li>Steve stated that it makes the most sense to defer to Unicode for
          valid identifier syntax and for individual projects to decide what
          constitutes a reasonable identifier.</li>
      <li>Steve asserted that following Unicode guidance should not be an
          on-going discussion for WG21.</li>
      <li>Jens reminded the group that we decided to defer to Unicode
          explicitly so that we would not have to decide what is a valid
          identifier.</li>
      <li>Robin explained that this topic is on the agenda because there was a
          change to UAX #31 and Annex E now has dangling-ish references.</li>
      <li>Robin reported that the change made to default identifiers was a
          simplification and that
          <a href="https://www.unicode.org/reports/tr55/">UTS #55 (Unicode Source Code Handling)</a>
          gives general guidance for identifiers.</li>
      <li>Robin noted that the provided guidance suggests adopting a profile
          from
          <a href="https://www.unicode.org/reports/tr31/#Mathematical_Compatibility_Notation_Profile">UAX #31 section 7.1</a>
          to allow additional characters that are not included in default
          identifiers.</li>
      <li>Robin stated that some implementations already allow those characters
          and that formally adding them to C++ should probably be pursued by a
          separate paper.</li>
      <li>Tom noted that those additional characters are for some mathematics
          symbols.</li>
      <li>Steve agreed that is something to consider, but is unrelated to the
          current issue.</li>
      <li>Tom asked if anyone had an argument to offer for why we should not
          accept the UAX #31 updates.</li>
      <li>No such arguments were offered.</li>
      <li>Tom asked for a volunteer to update annex E.</li>
      <li>Steve volunteered.</li>
      <li>Robin expressed interest in collaborating on a paper to adopt the
          <a href="https://www.unicode.org/reports/tr31/#Mathematical_Compatibility_Notation_Profile">Mathematical Compatibility Notation Profile</a>.</li>
      <li>Tom requested that Steve send updated wording to Jens to be included
          in the proposed resolution.</li>
      <li>Jens stated that the proposed resolution will require approval from
          EWG due to the minimum version requirement.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg4043">LWG 4043: <tt>"ASCII"</tt> is not a registered character encoding</a>:
    <ul>
      <li>Tom provided a brief introduction:</li>
        <ul>
          <li>Users expect "ASCII" to be a recognized encoding name, existing
              converters recognize it, the proposed resolution is that it be
              recognized as an alias of "US-ASCII".</li>
        </ul>
      </li>
      <li>Fraser asked if it is known why "ASCII" isn't already an alias for
          "US-ASCII" in the
          <a href="https://www.iana.org/assignments/character-sets/character-sets.xhtml">IANA character set registry</a>.</li>
      <li>Tom guessed that it is due to historic confusion regarding
          "extended ASCII" character sets.</li>
      <li>Tom shared a link to the IANA character set reference and quoted the
          first paragraph in chat.
          <blockquote class="quote">
            These are the official names for character sets that may be used in
            the Internet and may be referred to in Internet documentation.
            These names are expressed in ANSI_X3.4-1968 which is commonly called
            US-ASCII or simply ASCII.
            The character set most commonly use in the Internet and used
            especially in protocol standards is US-ASCII, this is strongly
            encouraged.
            The use of the name US-ASCII is also encouraged.
          </blockquote>
      <li>Steve noted that the IANA registry includes a "csASCII" alias.</li>
      <li>Fraser opined that this sounds like a historic issue.</li>
      <li>Steve recalled that some special handling for "cs" prefixed names
          was adopted.</li>
      <li>Tom replied that the <tt>std::text_encoding::id</tt> enumerators use
          the "cs" prefixed aliases with the "cs" prefix removed.</li>
      <li>Tom asked if anyone is opposed to adding the proposed "ASCII"
          alias.</li>
      <li>Jens noted that implementations already have lattitude to add
          additional names.</li>
      <li>Jens agreed we should add this particular alias, but not as a
          precedent for adding additional aliases later.</li>
      <li>Peter stated that ASCII is deserving of special consideration and is
          recognized around the world.</li>
      <li>Victor opined that the motivation in the LWG issue is a little weak,
          but that he isn't opposed.</li>
      <li>Tom reported that <tt>iconv()</tt> and ICU will already recognize it
          and opined that users will expect it to be recognized.</li>
      <li>Steve noted that implementors don't need our approval to add this
          alias.</li>
      <li><b>Poll 1: Approve the addition of "ASCII" as an alias for the US-ASCII IANA encoding.</b>
        <ul>
          <li><b>Attendees: 9</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg4044">LWG 4044: Confusing requirements for <tt>std::print</tt> on POSIX platforms</a>:
    <ul>
      <li>Victor introduced the issue:
        <ul>
          <li>Jonathan Wakely implemented support for <tt>std::print()</tt> in
              libstdc++ and encountered a significant performance issue due to
              how he interpreted the standard wording.</li>
          <li>When discussing <tt>std::print()</tt> in SG16, we didn't consider
              POSIX streams as a "Native Unicode API".</li>
          <li>Private correspondence with Jonathan clarified the intent and
              resolved the performance issues.</li>
        </ul>
      </li>
      <li>Victor guided discussion through the proposed wording.</li>
      <li>Victor highlighted the removal of the POSIX and <tt>isatty()</tt>
          related wording as the important change.</li>
      <li>Victor suggested that the moved text that encourages implementations
          to diagnose invalid code units be removed.</li>
      <li>Eddie agreed with striking the wording regarding diagnosing invalid
          code units.</li>
      <li>Eddie noted that checking for ill-formed code unit sequences imposes
          overhead.</li>
      <li>Steve asserted that <tt>isatty()</tt> is fragile and that its use
          complicates debugging since it leads to file redirection changing
          program behavior.</li>
      <li>Eddie asked Steve for clarification.</li>
      <li>Steve replied that <tt>isatty()</tt> is fragile because it is easy to
          cause <tt>isatty()</tt> to return false when the output is still
          going to the terminal.</li>
      <li><em>[ Editor's note: Compare the behavior of <tt>ls</tt> vs
          <tt>ls | cat</tt> on Linux for example. ]</em></li>
      <li>Eddie opined that tools should check the <tt>NO_COLOR</tt>
          environment variable.</li>
      <li>Steve insisted that <tt>isatty()</tt> is too low level for what
          <tt>std::print()</tt> is intended to do.</li>
      <li>Tom expressed support for dropping the wording regarding diagnosing
          invalid code units.</li>
      <li>Tom asked if the wording should state something else regarding the
          behavior when invalid code unit sequences are present but concluded
          that likely falls under implementation-defined behavior related to
          use of the native Unicode API.</li>
      <li>Jens asked if the Windows checks for code directed to a console have
          similar overhead concerns as calls to <tt>isatty()</tt> on POSIX
          systems.</li>
      <li>Victor replied affirmatively but noted that there is no known
          alternative at present.</li>
      <li>Victor stated that the check could become a no-op in the future if it
          becomes possible to check for use of a Unicode code page instead.</li>
      <li>Victor summarized that we can either do the wrong thing quickly or
          the right thing slowly.</li>
      <li>Jens expressed agreement for striking the wording regarding diagnosing
          invalid code unit sequences.</li>
      <li>Peter opined that the wording appears to be written from a Windows
          point of view and seems quite strange from a POSIX perspective.</li>
      <li>Peter suggested that the wording could discuss Windows
          specifically.</li>
      <li>Jens replied that Windows is specifically addressed in a note.</li>
      <li>Tom acknowledged that Peter has a valid point; the
          "native Unicode API" is only needed when writing directly to the
          stream is insufficient to produce the right result.</li>
      <li>Eddie advised caution regarding discounting the possibility that
          writing directly to the stream could produce the right result on
          Windows.</li>
      <li>Tom noted that Microsoft does ship versions of Windows that only
          support UTF-8 as the active code page and offered HoloLens as an
          example.</li>
      <li>Steve asked if implementors need this guidance.</li>
      <li>Victor replied that they do and that it took considerable exploration
          to determine exactly which functions were needed to achieve the right
          results.</li>
      <li>Jens commented that this is one of those rare places in the standard
          where we try to tell implementors what to do rather than just
          specifying the required behavior.</li>
      <li>Jens stated that the wording needs to be sufficient to guide
          implementors to the right result.</li>
      <li><b>Poll 2: Approve the LWG 4044 proposed resolution with the wording about diagnosing invalid code units removed.</b>
        <ul>
          <li><b>Attendees: 9</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li>Tom announced that the next meeting will be on 2024-03-13; the week
      before the Tokyo meeting.</li>
  <li>Tom requested suggestions for any papers or issues that need SG16 review
      prior to Tokyo.</li>
</ul>


</body>
