<!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-05-24 through 2023-09-27</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>P2995R0</td>
  </tr>
  <tr>
    <th>Date:</th>
    <td>2023-10-07</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-05-24 through 2023-09-27</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_05_24">
      May 24th, 2023</a></li>
  <li><a href="#2023_06_07">
      June 7th, 2023</a></li>
  <li><a href="#2023_07_12">
      July 12th, 2023</a></li>
  <li><a href="#2023_07_26">
      July 26th, 2023</a></li>
  <li><a href="#2023_08_23">
      August 23rd, 2023</a></li>
  <li><a href="#2023_09_13">
      September 13th, 2023</a></li>
  <li><a href="#2023_09_27">
      September 27th, 2023</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>
</ul>
</p>


<h1 id="2023_05_24">May 24th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2779r0">P2779R0: Make basic_string_view’s range construction conditionally explicit</a>.</li>
  <li><a href="https://wg21.link/p2863r0">P2863R0: Review Annex D for C++26</a>.</li>
  <li><a href="https://wg21.link/p2871r0">P2871R0: Remove Deprecated Unicode Conversion Facets From C++26</a>.</li>
  <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/p2872r0">P2872R0: Remove wstring_convert From C++26</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Alisdair Meredith</li>
  <li>Charlie Barto</li>
  <li>Corentin Jabot</li>
  <li>Eddie Nolan</li>
  <li>Fraser Gordon</li>
  <li>Giuseppe D'Angelo</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Mark Zeren</li>
  <li>Peter Bindels</li>
  <li>Peter Brett</li>
  <li>Robin Leroy</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2779r0">P2779R0: Make basic_string_view’s range construction conditionally explicit</a>:
    <ul>
      <li>Giuseppe presented an overview of the paper including relevant
          history:
        <ul>
          <li><a href="https://wg21.link/p1989">P1989R2 (Range constructor for std::string_view 2: Constrain Harder)</a>
              added an implicit <tt>std::string_view</tt> constructor that
              enables implicit conversion from any type that satisfies a set of
              constraints, one of which includes having a member type alias
              named <tt>traits_type</tt> that matches the
              <tt>std::string_view</tt> member of the same name.</li>
          <li><a href="https://wg21.link/p2499">P2499R0 (string_view range constructor should be explicit)</a>
              changed the new constructor to be declared <tt>explicit</tt> due
              to concerns involving ranges that do or do not contain an
              embedded null character; this broke the ability for string types
              to implicitly convert to <tt>std::string_view</tt>.</li>
          <li><a href="https://wg21.link/lwg3857">LWG 3857</a>
              removed the constraint requiring a matching <tt>traits_type</tt>
              member type alias based on the rationale that such a safety
              precaution is no longer necessary since conversions are now
              explicit.</li>
          <li>The proposed paper seeks to conditionally restore implicit
              conversions for string-like types without requiring modifications
              to those types to add conversion operators.</li>
          <li>Two options are proposed:
            <ul>
              <li>Option 1 adds an opt-in trait and makes the constructor
                  conditionally explicit based on the presence of a matching
                  member <tt>traits_type</tt> type alias.</li>
              <li>Option 2 makes the constructor conditionally explicit based on
                  the presence of a matching member <tt>traits_type</tt> type
                  alias without requiring an opt-in trait.</li>
            </ul>
          </li>
          <li>Qt has provided a <tt>QStringView</tt> class with an
              <a href="https://doc.qt.io/qt-6/qstringview.html#QStringView-7">implicit constructor that accepts a range</a>
              that has worked well in practice for a decade.</li>
        </ul>
      </li>
      <li>PBrett asked what the essential nature of a string-like type is.</li>
      <li>Giuseppe responded that it is a contiguous sequence of characters
          and associated character classification traits.</li>
      <li>PBrett argued for substitution of "code units" for "characters".</li>
      <li>Zach noted that the <tt>traits_type</tt> name might be used by types
          that are not string-like types, stated that he does not typically add
          a <tt>traits_type</tt> to his own string-like types, and asked what is
          commonly done in practice.</li>
      <li>Giuseppe responded that the paper lists the results of a survey of
          various projects for occurrences of the <tt>traits_type</tt> name and
          found that it is strongly correlated with string-like types but that
          there are string-like types that don't have such a member.</li>
      <li>Giuseppe acknowledged that the <tt>traits_type</tt> name is quite
          generic.</li>
      <li>Victor expressed opposition to option 2 since it relies on what he
          considers to be a legacy feature and that <tt>traits_type</tt> is, in
          practice, always <tt>std::char_traits</tt>.</li>
      <li>Victor asserted that implicit conversions and implicit interoperation
          with the standard library are not desired for Folly's
          <tt>fbstring</tt>.</li>
      <li>Victor stated that he is ok-ish with option 1.</li>
      <li>Tom asked Victor to further explain his concerns and the damage he
          fears the implicit conversions would cause.</li>
      <li>Victor replied that use of <tt>fbstring</tt> is no longer encouraged
          and the proposed change would facilitate continued usage.</li>
      <li>Victor noted that the proposed changes could also impact overload
          resolution in generic code and potentially introduce overload
          resolution failures due to ambiguity.</li>
      <li>Corentin lamented the ability for programmers to specialize
          <tt>std::char_traits</tt> for their own user-defined types and stated
          he plans to propose deprecating or removing that allowance.</li>
      <li>Corentin explained that the interface that <tt>std::char_traits</tt>
          provides is not a good match for how text processing works in
          practice.</li>
      <li>Corentin asserted that increased use of <tt>std::char_traits</tt>
          should be discouraged.</li>
      <li>Corentin opined that option 1 is fine but that option 2 is
          problematic in the long run.</li>
      <li>Giuseppe acknowledged Corentin's position.</li>
      <li>Corentin clarified that programmers should not be encouraged to use
          a different type than <tt>std::char_traits</tt> but rather that they
          should be encouraged not to use a char-traits-like type at all.</li>
      <li>Tom summarized his understanding of the concerns; the proposed change
          could encourage programmers to add a <tt>traits_type</tt> member type
          alias of <tt>std::char_traits</tt> to classes that otherwise wouldn't
          define the type alias solely to enable implicit conversions to
          <tt>std::string_view</tt>.</li>
      <li>Zach argued for not enabling such implicit conversions at all on the
          basis that <tt>std::string_view</tt> is intended to be implicitly
          convertible from other standard library types and that explicit
          conversions are appropriate elsewhere.</li>
      <li>Alisdair opined that the right approach would be for types to opt
          themselves in to an implicit conversion.</li>
      <li>Alisdair asserted that <tt>std::char_traits</tt> is not legacy and
          that it cannot be removed without significant ABI impact.</li>
      <li>Alisdair stated that the matching <tt>traits_type</tt> constraint is
          a good heuristic and that the opt-in trait in option 1 is so specific
          that he would have a hard time supporting it.</li>
      <li>Jens noted that the proposed wording for option 1 requires both the
          opt-in string-like-type trait and the matching <tt>traits_type</tt>
          constraint to enable implicit conversions.</li>
      <li>Jens expressed a preference for an option that proposed only the
          string-like-type trait.</li>
      <li>Jens stated that the wording needs to be rebased on the current
          working paper since the struck wording has already been removed.</li>
      <li>Jens suggested <tt>is_string_view_like</tt> might not be the best
          choice of name for the opt-in trait and suggested <tt>enable_view</tt>
          as an example name for similar opt-in traits.</li>
      <li>Giuseppe acknowledged the suggestion and stated that the name can be
          changed.</li>
      <li>Jens noted that it doesn't matter how string-view-like the source type
          is as long as it provides contiguous storage and opts itself in.</li>
      <li>Jens agreed with not wanting to encourage the addition of an otherwise
          unused <tt>traits_type</tt> member.</li>
      <li>Jens observed that <tt>is_string_view_like</tt> is false by
          default.</li>
      <li>Jens suggested that, if it is desirable to provide a safety check on a
          matching <tt>traits_type</tt> member, that the
          <tt>is_string_view_like</tt> trait can support a mechanism to enable
          that.</li>
      <li>Jens expressed a preference for postponing a poll to forward the paper
          until it has been rebased on the current working paper.</li>
      <li>Various poll options were discussed but it was decided that polling be
          postponed pending an updated paper revision with wording rebased on
          the current working paper and an additional option to enable implicit
          conversions based solely on the opt-in trait.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2863r0">P2863R0: Review Annex D for C++26</a>:
    <ul>
      <li>Alisdair introduced this and the following papers.</li>
      <li>Tom explained his understanding of the ramifications for removal of
          standard library features; that an implementor may choose not to
          provide the removed features or may choose to provide them since the
          removed names are reserved as "zombie" names.</li>
      <li>Alisdair acknowledged the intent, but noted that the standard
          currently lacks wording to support zombification of explicit template
          specializations.</li>
      <li>Alisdair explained that there are four deprecated subclauses that are
          relevant to SG16;
          <a href="http://eel.is/c++draft/depr.locale.stdcvt">D.26 ([depr.locale.stdcvt])</a>,
          <a href="http://eel.is/c++draft/depr.conversions">D.27 ([depr.conversions])</a>,
          <a href="http://eel.is/c++draft/depr.locale.category">D.28 ([depr.locale.category])</a>,
          and
          <a href="http://eel.is/c++draft/depr.fs.path.factory">D.29 ([depr.fs.path.factory])</a>.</li>
      <li>PBindels stated that
          <a href="http://eel.is/c++draft/depr.str.strstreams">D.15 ([depr.str.strstreams])</a>
          and
          <a href="http://eel.is/c++draft/depr.string.capacity">D.25 ([depr.string.capacity])</a>
          have to do with text facilities but that he reviewed them and
          concluded that the functionality is not strongly relevant for
          SG16.</li>
      <li>Alisdair stated that, for <tt>std::filesystem::u8path</tt>, per
          <a href="https://wg21.link/lwg3840">LWG 3840</a>,
          there have been recent comments that removal would be
          problematic.</li>
      <li>Tom stated that the LWG issue was recently discussed in LEWG but that
          the LWG issue does not appear to have been updated to reflect that
          discussion.</li>
      <li><em>[ Editor's note: LEWG discussed the LWG issue during its
          <a href="https://wiki.edg.com/bin/view/Wg21telecons2023/LWG3840">2023-01-10 telecon</a>.
          ]</em></li>
      <li>Alisdair stated that deprecated features should either be undeprecated
          or removed and noted that this feature has been deprecated since
          C++20.</li>
      <li>Jens expressed concern regarding Billy O'Neal's comment in the LWG
          issue that deprecation of <tt>u8path</tt> was one of the reasons that
          vcpkg discontinued use of <tt>std::filesystem</tt>.</li>
      <li>Jens stated that SG16 should offer an opinion.</li>
      <li>Corentin replied that there was a poll in LEWG in January and that
          there was no consensus to undeprecate <tt>u8path</tt>.</li>
      <li>Corentin stated that a mechanism to access a sequence of <tt>char</tt>
          that holds UTF-8 code units as-if it were a sequence of
          <tt>char8_t</tt> is a feature that we should have; we're missing a way
          to pass such a sequence to the <tt>std::filesystem::path()</tt>
          constructor such that it is interpreted as UTF-8.</li>
      <li>Tom noted that Corentin has a paper on that topic.</li>
      <li><em>[ Editor's note: See
          <a href="https://wg21.link/p2626">P2626 (charN_t incremental adoption: Casting pointers of UTF character types)</a>.
          ]</em></li>
      <li>Alisdair noted that, if removed, <tt>u8path</tt> would be added to the
          list of zombie names, so implementors that wish to continue providing
          it may do so.</li>
      <li>PBindels opined that <tt>u8path</tt> provides a solution to work
          around legacy issues but that Corentin's P2626 provides a proper
          solution.</li>
      <li>PBindels suggested that we should neither undeprecate nor remove
          <tt>u8path</tt> until a proper solution is in place.</li>
      <li>Alisdair stated that he can update the paper to reflect that guidance
          and to note further action as dependent on P2626.</li>
      <li>Charlie agreed with not removing <tt>u8path</tt> without a proper
          alternative.</li>
      <li>Charlie noted that, if <tt>u8path</tt> is zombified, that implementors
          can continue to provide it, but that portability is lost.</li>
      <li>Charlie stated that he didn't see a reason to remove <tt>u8path</tt>;
          that it isn't harmful.</li>
      <li>Alisdair acknowledged that a migration path is needed.</li>
      <li>Tom explained that the original motivation for deprecation was to
          dissuade continuing to provide standard library functions that require
          UTF-8 data in <tt>char</tt>-based storage.</li>
      <li>Tom noted that <tt>u8path</tt> and the deprecated
          <tt>std::codecvt</tt> facets were the only standard library features
          that did so.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2871r0">P2871R0: Remove Deprecated Unicode Conversion Facets From C++26</a>:
    <ul>
      <li>Alisdair presented the paper:
        <ul>
          <li>These facets were deprecated because they did not provide error
              handling capabilities and could not reasonably be extended.</li>
          <li>There are some implementations that do not issue deprecation
              warnings.</li>
        </ul>
      </li>
      <li>Corentin noted the work in progress and general plan to provide
          replacements for C++26 and suggested waiting to remove them pending
          that work.</li>
      <li>Jens agreed and stated that removal without replacements is
          ill-advised unless these are actively causing harm.</li>
      <li>Tom noted that conversions are possible through the <tt>mbrtoc*</tt>
          and <tt>c*rtomb</tt> family of functions though those have their own
          issues.</li>
      <li>Victor stated that the <tt>codecvt</tt> facets are so challenging to
          use that not having a replacement isn't really a problem.</li>
      <li>Alisdair noted that implementors can continue to provide them thanks
          to zombification.</li>
      <li>Alisdair reported that, per the paper, LEWG and SG16 previously
          recommended removal during the C++23 cycle, but that action wasn't
          completed.</li>
      <li>Alisdair reminded the group that <tt>codecvt_utf</tt> and
          <tt>codecvt_utf1</tt> convert to and from UCS-2 or UTF-32 depending
          on the size of the first template parameter.</li>
      <li>PBrett asked for any objections to removal.</li>
      <li>No objections were reported.</li>
      <li>Alisdair stated he will take that feedback back to LEWG.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2873r0">P2873R0: Remove Deprecated Locale Category Facets For Unicode from C++26</a>:
    <ul>
      <li>Tom explained that these facets were deprecated because they convert
          to and from UTF-8 in <tt>char</tt>-based storage rather than between
          the multibyte encoding like the non-deprecated facets do.</li>
      <li>Tom reported that <tt>char8_t</tt>-based replacements were added as
          replacements, but those were a mistake because they won't be used by
          <tt>char</tt>-based streams anyway.</li>
      <li><em>[ Editor's note:
          <a href="https://wg21.link/lwg3767">LWG 3767</a>
          tracks deprecating the <tt>char8_t</tt>-based facets. ]</em></li>
      <li>PBrett asked for any objections to removal.</li>
      <li>No objections were reported.</li>
      <li>Corentin spoke in favor of removal.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2872r0">P2872R0: Remove wstring_convert From C++26</a>:
    <ul>
      <li>Giuseppe asked if the paper includes removal of
          <tt>std::wbuffer_convert</tt>.</li>
      <li>Alisdair confirmed that it does.</li>
      <li>Alisdair explained that these were deprecated because the example for
          <tt>std::wstring_convert</tt> used another deprecated feature,
          <tt>std::codecvt_utf8</tt> and, due to other underspecification
          concerns, noone was motivated to fix them.</li>
      <li>Alisdair asked if SG16 is the right group to address this.</li>
      <li>PBrett responded affirmatively and stated that SG16 is the group that
          misunderstands <tt>wchar_t</tt> the least.</li>
      <li>Alisdair noticed some issues with the paper and concluded that updates
          are required before the paper is ready for any action to be taken on
          it.</li>
    </ul>
  </li>
  <li>Tom stated that the next meeting is tentatively scheduled for 2023-06-07
      and will likely continue review of
      <a href="https://wg21.link/p2779">P2779 (Make basic_string_view’s range construction conditionally explicit)</a>
      and
      <a href="https://wg21.link/p2872">P2872 (Remove wstring_convert From C++26)</a>
      if updated revisions are available followed by an initial review of
      <a href="https://wg21.link/p2845">P2845 (Formatting of std::filesystem::path)</a>.</li>
  <li>Zach reported that he expects to have a new revision of
      <a href="https://wg21.link/p2728">P2728 (Unicode in the Library, Part 1: UTF Transcoding)</a>
      available soon after the Varna meeting.</li>
</ul>


<h1 id="2023_06_07">June 7th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2779r1">P2779R1: Make basic_string_view’s range construction conditionally explicit</a>.</li>
  <li><a href="https://wg21.link/p2872r1">P2872R1: Remove wstring_convert From C++26</a>.</li>
  <li><a href="https://wg21.link/p2845r0">P2845R0: Formatting of std::filesystem::path</a>.</li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Alisdair Meredith</li>
  <li>Charlie Barto</li>
  <li>Corentin Jabot</li>
  <li>Fraser Gordon</li>
  <li>Giuseppe D'Angelo</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Mark Zeren</li>
  <li>Peter Brett</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2779r1">P2779R1: Make basic_string_view’s range construction conditionally explicit</a>.
    <ul>
      <li><em>[ Editor's note: D2779R1 was the active paper under discussion at
          the telecon.
          The agenda and links used here reference P2749R1 since the links to
          the draft paper were ephemeral.
          The published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>Giuseppe summarized the paper and changes since the last revision:
        <ul>
          <li>The paper endeavors to identify a compromise position for the
              issues that have resulted in multiple changes to how the
              <tt>std::basic_string_view</tt> range constructor is
              specified.</li>
          <li>Option 2 from the previous revision is still present though there
              was not much support for this option in the last discussion.</li>
          <li>Option 1 follows existing precedent for type traits that enable
              some functionality; this option has been divided into two
              sub-options.</li>
          <li>Option 1-A provides a type trait that enables conversion without
              regard to the <tt>traits_type</tt> member.</li>
          <li>Option 1-B provides the type trait from option 1-A as well as an
              additional type trait that can be used to enable conversion that
              is sensitive to the <tt>traits_type</tt> member.</li>
        </ul>
      </li>
      <li>Tom asked if the intent is for the trait to be used only for
          conversion to <tt>std::string_view</tt> or for conversion to any
          string_view-like type.</li>
      <li>Giuseppe responded that it is intended to be used for conversion to
          any string_view-like type.</li>
      <li>Jens suggested in chat: "You can also define
          enable_string_view_conversion in a way so that the user specialization
          can compare char_traits, if so desired (or not)."</li>
      <li>Jens' suggestion received several positive responses.</li>
      <li>Alisdair, following up on Jens' suggestion in chat, asked if the
          traits in option 1-B could be merged.</li>
      <li>Giuseppe confirmed that they could be.</li>
      <li>Alisdair indicated that would be his preference.</li>
      <li>Alisdair stated that the conversion could be enabled based on a class
          member similar to how transparent key comparison for associative
          containers is enabled via the <tt>is_transparent</tt> member of the
          compare class.</li>
      <li>Giuseppe acknowledged that approach would work as well.</li>
      <li>Tom noted that approach would require modifying the class.</li>
      <li>Alisdair responded that the trait could still be specialized but could
          be defaulted based on the presence of a member.</li>
      <li>Jens stated that the most convenient option would be to define a
          conversion operator with the trait available as a fallback.</li>
      <li>Jens expressed a preference for a single trait with template
          parameters such that a specialization can be written to explicitly
          match <tt>traits_type</tt> or <tt>std::char_traits</tt> as
          desired.</li>
      <li>Jens noted that <tt>enable_string_view_conversion_with_traits</tt>
          still requires comparison with <tt>std::char_traits</tt> or a
          <tt>traits_type</tt> member.</li>
      <li>Jens suggested that third party string_view-like classes can provide
          their own trait to enable implicit conversions.</li>
      <li>Giuseppe responded that the goal is to enable interconvertibility
          between different string types.</li>
      <li>Giuseppe noted that the proposal doesn't require comparisons with
          specific type or member names.</li>
      <li>Zach stated that he doesn't find the problem that the paper intends
          to address compelling and noted that <tt>std::string_view</tt> is
          available as a vocabulary type.</li>
      <li>Zach noted that working around the lack of an implicit conversion
          just requires slightly more code; explicit construction of a
          <tt>std::string_view</tt> object.</li>
      <li>Victor requested that the two traits in option 1-B be merged.</li>
      <li>Victor agreed with Alisdair's suggestion to default the trait to
          enable based on the presence of a class member.</li>
      <li>Victor asserted that only the author of a class should opt a class
          into the proposed behavior; not users of the class.</li>
      <li>Victor repeated his opposition to enabling implicit third party
          interoperation.</li>
      <li>Corentin stated that most of the proposed behavior should be being
          discussed in LEWG rather than in SG16 and that SG16 just needs to
          provide a recommendation whether use of <tt>std::char_traits</tt>
          is a good heuristic.</li>
      <li>PBrett responded that there is an SG16 question concerning which
          types are sufficiently text-like.</li>
      <li>PBrett asked for poll suggestions.</li>
      <li>Tom noted that discussion revealed other options that should be
          explored.</li>
      <li>Tom suggested polling the desire to enable interconvertibility
          across any/all string-like types in the ecosystem.</li>
      <li>Poll wordsmithing ensued.</li>
      <li><b>Poll 1.1: Any opt-in to implicit range construction of
          <tt>std::string_view</tt> should be explicit on a per-type basis.</b>
        <ul>
          <li><b>Attendees: 12 (1 abstention)</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">2</th>
                <th style="text-align:right">8</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Strong consensus.</b></li>
          <li><b>A: If types have character traits, we should be making use of
              them to determine compatibility.</b></li>
        </ul>
      </li>
      <li>Jens responded to the against rationale by stating that use of
          character traits is not excluded; per-type enablement could be
          conditional on matching traits.</li>
      <li><b>Poll 1.2: The standard library should provide a general-purpose
          facility for enablement of implicit interconvertibility between
          string and string_view-like types (including UDTs).</b>
        <ul>
          <li><b>Attendance: 12 (2 abstentions)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">1</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
        </ul>
      </li>
      <li><b>Poll 1.3: A solution to the problem stated in P2779 needs to be
          included in the C++ standard library.</b>
        <ul>
          <li><b>Attendance: 12 (1 abstention)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">1</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">5</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
        </ul>
      </li>
      <li>Tom stated that he will record the poll results in the paper tracker
          and that it will be up to the LEWG chair to decide what to do
          next.</li>
      <li>PBrett suggested that more examples of how this proposal could
          alleviate programming challenges</li>
      <li>might help to increase motivation.</li>
      <li>Tom agreed and noted that the large proportion of N votes presumably
          reflects insufficient motivation.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2872r1">P2872R1: Remove wstring_convert From C++26</a>.
    <ul>
      <li><em>[ Editor's note: D2872R1 was the active paper under discussion at
          the telecon.
          The agenda and links used here reference P2872R1 since the links to
          the draft paper were ephemeral.
          The published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>Alisdair stated that, If feedback is light, that he will incorporate
          it and publish the paper as P2872R1; otherwise, he will publish
          P2872R1 as-is and incorporate the feedback in a newer revision.</li>
      <li>Alisdair explained that <tt>wbuffer_convert</tt> and
          <tt>wstring_convert</tt> have been deprecated for three standard
          releases now.</li>
      <li>Alisdair noted that removal permits implementors to continue to
          provide the functionality thanks to the additions to zombie
          names.</li>
      <li>Alisdair indicated that wording updates might be needed, but that LWG
          will handle that.</li>
      <li>Alisdair explained that the deprecation was motivated by
          underspecification and dependence on other deprecated features like
          <tt>std::codecvt_utf8</tt>.</li>
      <li>Alisdair reported that there are currently four related open LWG
          issues and that reviving the feature would require more.</li>
      <li>Corentin stated that, without <tt>std::codecvt_utf8</tt>, the
          standard no longer provides features needed to use these types.</li>
      <li>Alisdair agreed and explained that programmers would have to provide
          their own <tt>std::codecvt</tt> facet.</li>
      <li>Corentin acknowledged the requirement, but observed that programmers
          could more easily just implement the needed conversion.</li>
      <li>Victor opined that these types provide little value since they are
          just light wrappers anyway.</li>
      <li>Victor reported that a search of the projects he works on found a few
          uses, but that those uses should be replaced anyway.</li>
      <li>PBrett asked if anyone had an objection to removing these
          features.</li>
      <li>No objections were raised.</li>
      <li>MarkZ reported that a Github search identified few uses.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2845r0">P2845R0: Formatting of std::filesystem::path</a>.
    <ul>
      <li>Victor introduced the paper:
        <ul>
          <li><a href="https://wg21.link/p1636">P1636 (Formatters for library types)</a>
              previously proposed formatting for <tt>std::filesystem::path</tt>
              but was specified to use the <tt>native()</tt> member function
              which might require transcoding and had no provisions for
              handling of non-printable characters.</li>
          <li>This paper proposes a formatter that performs proper transcoding
              and substitutes escape sequences for non-printable characters and
              ill-formed code units.</li>
        </ul>
      </li>
      <li>Victor noticed a missing doublequote character in the first source
          code example in section 2, "Problems".</li>
      <li>Victor reported that some minor issues have been fixed in a draft R1
          revision.</li>
      <li>Corentin asked if backslash path delimiters on Windows would be
          formatted with escape sequences.</li>
      <li>Victor confirmed that they would be, that such substitution might be
          surprising, but is consistent with <tt>std::quoted()</tt>.</li>
      <li>Victor noted that an additional format specifier could be provided
          to choose an alternate behavior.</li>
      <li>Corentin asked about use of the debug specifier, "{:?}".</li>
      <li>Victor replied that the escaped format is proposed as the default
          behavior.</li>
      <li>Charlie asserted that some lattitude is needed to choose an alternate
          escape character since backslash in paths has an important meaning
          on Windows.</li>
      <li>Charlie noted that an alternate escape character could be surprising
          and would create an inconsistency across platforms.</li>
      <li>PBrett asked about adding a specifier that enables specifying a
          different escape character.</li>
      <li>Victor responded that such a specifier would be cumbersome and that
          there are other options such as performing a transformation.</li>
      <li>Victor stated that there are use cases for both an escaped and a
          non-escaped variant.</li>
      <li>Tom presented a few use cases including formatting for generic text,
          byte preserved for filesystem access, punycode for URLs, and quoted
          for shell scripts.</li>
      <li>Tom suggested that most transformations should be done outside of
          formatting.</li>
      <li>Corentin stated that the default behavior should just escape
          ill-formed code units and that the debug format specifier could be
          used to escape problematic characters.</li>
      <li>Victor replied that quoting is useful but not always needed.</li>
      <li>Tom suggested that a specifier could be added to opt in to
          quoting.</li>
      <li>PBrett expressed two high level use cases:</li>
        <ul>
          <li>The need to format the path precisely such that it can be used
              to open a file.</li>
          <li>The need to format the path for textual display in a format
              friendly to humans.</li>
        </ul>
      </li>
      <li>PBrett opined that the paper does not clearly define the problem it
          intends to solve.</li>
      <li>PBrett noted that, in
          <a href="https://docs.gtk.org/glib">GLib</a>,
          functions are provided to request a file name suitable for display
          as valid UTF-8 or as a byte array.</li>
      <li>Victor replied that the goal of the paper is to address the issues
          discovered from prior review of
          <a href="https://wg21.link/p1636">P1636 (Formatters for library types)</a>.</li>
      <li>Victor stated that additional use cases can be addressed as
          needed.</li>
      <li>Zach reported that Python provides the functionality this paper is
          proposing and noted that its formatters will double Windows path
          separators.</li>
      <li>Zach stated that Python allows printing unformatted paths by treating
          paths as a string and that C++ can do so as well.</li>
      <li>Zach agreed that some kind of escaping and quoting is needed.</li>
      <li><em>[ Editor's note: Corentin later
          <a href="https://lists.isocpp.org/sg16/2023/06/3886.php">posted a message to the SG16 mailing list</a>
          that demonstrates Python's behavior with a
          <a href="https://godbolt.org/z/7sf5xPPsc">Compiler Explorer link</a>.
          ]</em></li>
      <li>Jens asserted that, due to various quirks with
          <tt>std::filesystem::path</tt>, that the paper should cover the
          motivation and design space and not solely focus on addressing the
          issues found from review of P1636.</li>
      <li>Jens stated that the paper should discuss, for example, the
          implication of using backslashes in the syntax of character escapes
          in formatted paths.</li>
      <li>PBrett agreed.</li>
      <li>PBrett noted that we were out of time and that additional review will
          be needed to discuss encoding issues.</li>
    </ul>
  </li>
  <li>Tom stated that the next meeting is scheduled for 2023-06-28, that there
      are several LWG issues awaiting review, and that Zach is working on a
      revision of
      <a href="https://wg21.link/p2728">P2728 (Unicode in the Library, Part 1: UTF Transcoding)</a>.</li>
  <li><em>[ Editor's note: The following meeting was canceled due to summer
      vacations. ]</em></li>
  <li>Zach stated an expectation to have a new revision available in the next
      two weeks.</li>
</ul>


<h1 id="2023_07_12">July 12th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p1030r5">P1030R5: std::filesystem::path_view</a>:
    <ul>
      <li>Discuss what to do in lieu of overloads with <tt>std::locale</tt> parameters.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2845r0">P2845R0: Formatting of std::filesystem::path</a>:
    <ul>
      <li>Continue review.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg3944">LWG 3944: Formatters converting sequences of char to sequences of wchar_t</a>:
    <ul>
      <li>Initial review.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Charlie Barto</li>
  <li>Fraser Gordon</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Mark de Wever</li>
  <li>Nathan Owen</li>
  <li>Niall Douglas</li>
  <li>Peter Brett</li>
  <li>Robin Leroy</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p1030r5">P1030R5: std::filesystem::path_view</a>:
    <ul>
      <li>Niall stated that, during LEWG discussion in Varna, LEWG approved
          removal of <tt>std::locale</tt> function overloads that were added
          for compatibility with <tt>std::filesystem::path</tt>.</li>
      <li>Niall noted that, for each overload set that has an overload with a
          <tt>std::locale</tt> parameter, there is an overload that does
          not.</li>
      <li>PBrett asked for an explanation of the concerns with the overloads
          that work with <tt>std::locale</tt>.</li>
      <li>Niall responded that locale support generally delegates conversion to
          the OS where they are handled efficiently, but conversions performed
          via <tt>std::locale</tt> impose considerable performance overhead;
          possibly including multiple conversions on some platforms.</li>
      <li><em>[ Editor's note: conversions controlled by <tt>std::locale</tt>
          require use of the <tt>std::codecvt</tt> facet which, per
          <a href="http://eel.is/c++draft/filesystems#fs.path.construct-6">[fs.path.construct]p6</a>,
          may require multiple conversions. ]</em></li>
      <li>Niall stated that a replacement for <tt>std::locale</tt> would be
          welcome.</li>
      <li>PBrett opined that, in his experience, treating paths as having an
          encoding leads to sadness.</li>
      <li>PBrett stated that a lossy conversion to a definitive encoding can
          be used to display paths.</li>
      <li>Niall noted that the proposed <tt>path_view</tt> supports a raw byte
          encoding and provides rendering operations.</li>
      <li>PBrett asked if the facility provides features to produce a path
          suitable for display purposes.</li>
      <li>Niall replied that such formatting falls more in the domain of
          <a href="https://wg21.link/p2845">P2845 (Formatting of std::filesystem::path)</a>
         and that he has been in discussion with Victor.</li>
      <li>PBrett asked if there is a plan to provide a formatter for
          <tt>path_view</tt>.</li>
      <li>Niall suggested that such a formatter behave the same as for
          <tt>std::filesystem::path</tt>.</li>
      <li>Victor summarized observations made during the LEWG discussion:
        <ul>
          <li><tt>std::locale</tt> was present in <tt>constexpr</tt> overloads;
              that issue is easily solved by removing the <tt>constexpr</tt>
              specifier from those declarations.</li>
          <li>the <tt>std::locale</tt> parameter is only present to support
              encoding conversions, but those conversions are better handled by
              an interface designed for such conversions.</li>
        </ul>
      </li>
      <li>Victor noted that <tt>std::codecvt</tt> is not an efficient method
          for transcoding.</li>
      <li>Victor opined that the overloads with a <tt>std::locale</tt>
          parameter are not known to be needed and can be added back later,
          perhaps in a more restrictive form, if desired.</li>
      <li>Niall asked Victor if he is suggesting that the existing
          <tt>std::filesystem::path</tt> overloads with a <tt>std::locale</tt>
          parameter should be deprecated.</li>
      <li>Victor replied that he would be happy to write such a paper at some
          future point.</li>
      <li>Tom asked why there is a <tt>compare()</tt> overload with a
          <tt>std::locale</tt> parameter.</li>
      <li>Niall responded that comparisons are shallow by default and
          <tt>compare()</tt> is provided to allow for more comprehensive
          equivalence comparisons.</li>
      <li>Niall explained that the <tt>std::locale</tt> parameter is used to
          convert each path to a common form that is then compared.</li>
      <li>PBrett expressed an assumption that the <tt>std::locale</tt>
          parameter would be used for collation purposes using the
          <tt>std::collate</tt> facet.</li>
      <li>Hubert asked why collation would be relevant for equality.</li>
      <li>PBrett asked if, given a set of <tt>path_view</tt> objects, whether
          the <tt>compare()</tt> operation could be used to order them.</li>
      <li>Zach responded that such collation might be better performed using
          features outside of the <tt>std::filesystem</tt> library.</li>
      <li>Jens stated that the wording in the paper is suggestive that only
          the encoding is intended to be consumed from the locale object.</li>
      <li>Jens observed that removal of the <tt>std::locale</tt> parameter
          results in a loss of transcoding facilities, but since what was
          provided was so thin, it isn't much of a loss.</li>
      <li>Victor stated that the equivalent facility in <tt>path_view</tt> of
          the <tt>std::locale</tt> based <tt>std::filesystem::path</tt>
          construction is the locale dependent <tt>render()</tt> member
          function.</li>
      <li>Niall explained that the reference implementation of the locale
          dependent <tt>render()</tt> member uses the <tt>std::locale</tt>
          object to convert a path to UTF-8 and then compares it.</li>
      <li>Tom expressed confusion, stated that <tt>std::locale</tt> doesn't
          support conversion to UTF-8, and then realized the reference
          implementation is probably using the <tt>char8_t</tt> codecvt
          facets that don't actually convert between the locale encoding.</li>
      <li>Niall responded that he is not aware of anyone that uses
          <tt>std::locale</tt> with the filesystem.</li>
      <li>Victor pondered interaction with <tt>std::format</tt> and
          <tt>std::print</tt> and whether it would make sense for
          <tt>path_view</tt> to also rely on the literal encoding to detect
          UTF-8 encoding; that would enable construction with
          <tt>char</tt>-based data to be saved as <tt>char8_t</tt>.</li>
      <li>Tom expressed some reservations; programmers might compile with a
          <tt>/utf-8</tt> or equivalent option, but file names produced or
          provided at run-time might be differently encoded.</li>
      <li>Hubert expressed concerns regarding implementation experience
          obtained so far regarding preservation of the literal encoding for
          use by the standard library.</li>
      <li><b>Poll 1: Modify P1030R6 "std::filesystem::path_view" to restore
          function overloads with locale parameters.</b>
        <ul>
          <li><b>Attendees: 12 (4 abstentions)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">4</th>
                <th style="text-align:right">2</th>
              </tr>
            </table>
          </li>
          <li><b>Consensus against.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2845r0">P2845R0: Formatting of std::filesystem::path</a>:
    <ul>
      <li>Tom apologized for his delinquency in producing a meeting summary for
          the previous discussion on this paper that took place at the prior
          SG16 meeting.</li>
      <li>Victor summarized his understanding of the direction from the prior
          meeting; to explore more options for quoting and escaping.</li>
      <li>PBrett explained a desired ability to obtain a close approximation of
          a path validly encoded for display purposes and stated that the paper
          does not currently provide sufficient detail.</li>
      <li>Victor asked for confirmation that Peter wants the path formatted
          without any transformation, no loss of information, no quoting, and
          perhaps just escaping for invalid code unit sequences.</li>
      <li>PBrett explained that he wants three version:
        <ul>
          <li>one that provides the raw bytes; <tt>path_view</tt> provides that,
              but <tt>std::filesystem::path</tt> does not.</li>
          <li>one that understands encoding and provides the path unmodified
              with the exception of substitution characters for invalid code
              unit sequences.</li>
          <li>one with quotes and escape sequences for problematic
              characters.</li>
        </ul>
      </li>
      <li>Niall stated that, for both <tt>std::filesystem::path</tt> and
          <tt>path_view</tt>, it is possible to obtain the path as a string or
          to visit the components with a lambda.</li>
      <li>Jens asked for confirmation that <tt>std::format</tt> includes a
          debug specifier that enables a string to be printed with escape
          sequences for problematic characters.</li>
      <li>Victor confirmed that is the case and stated that it could be used
          for paths such that the default formatting provides the second option
          PBrett listed.</li>
      <li>Jens asked what the output would be for the Belarusian example in the
          paper for arbitrary code pages used in practice.</li>
      <li>Victor replied that, in either case, the same substitutions would be
          performed.</li>
      <li>Jens expressed approval and noted that behavior would be consistent
          with choices previously made.</li>
      <li>Mark observed that the options discussed so far, with an exception
          for the debug specifier, would retain newline characters.</li>
      <li>PBrett acknowledged the behavior and noted that additional
          translations can be applied on the formatted result as needed;
          e.g., to substitute a space for the newline character.</li>
      <li>Niall expressed frustration regarding rendering paths in quotes since
          quote characters are also valid path characters.</li>
      <li>Tom acknowledged feeling similary frustrated by that.</li>
      <li>PBrett stated that quotes would only be present when the debug
          specifier is used.</li>
      <li>Niall pondered whether an additional format specifier to format the
          path with escape sequences but without quotes is warranted.</li>
      <li>Tom responded that additional such options could be recognized by the
          <tt>formatter</tt> specialization.</li>
      <li>Zach asked how control characters like RTL isolates should be handled;
          whether they should be ignored when formatting for display but
          preserved by the debug format.</li>
      <li>PBrett replied that he doesn't have experience with those in path
          names but that he would expect them to be handled as a custom
          translation.</li>
      <li>Zach suggested such characters should probably be passed through when
          formatting for display.</li>
      <li>PBrett asked if the paper should be updated to address the
          <tt>path_view</tt> proposal.</li>
      <li>Victor replied that <tt>path_view</tt> should be handled separately
          since there are additional complications for the byte case.</li>
      <li>Tom stated that the consensus direction seems pretty clear for a
          paper revision.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg3944">LWG 3944: Formatters converting sequences of char to sequences of wchar_t</a>:
    <ul>
      <li>Mark summarized the issue:
        <ul>
          <li>In C++20, it was an intentional design decision to not support
              formatting of <tt>char</tt>-based string arguments when
              formatting for <tt>wchar_t</tt>.</li>
          <li>In C++23, such formatting was inadvertently added via support for
              range formatting since a range might have a <tt>char</tt> element
              type.</li>
        </ul>
      </li>
      <li>PBrett asked Mark what his preferred resolution is.</li>
      <li>Mark replied with a preference to preserve formatting of individual
          characters of type <tt>char</tt> in general but to disable formatting
          of ranges with a <tt>char</tt> element type.</li>
      <li>Mark noted that such range formatting probably wouldn't produce the
          intended result when the characters are, for example, individual
          UTF-8 code units.</li>
      <li>PBrett expressed skepticism that the reported formatting was
          intentional.</li>
      <li>Tom asked why a different conclusion is reached for formatting of an
          individual character vs an individual character in a range.</li>
      <li>Hubert replied that a range of individual code units is more
          string-like.</li>
      <li>Niall stated that, in principle, the range could be iterated to
          decode characters.</li>
      <li>PBrett agreed but noted that doing so would require encoding
          information.</li>
      <li>Niall acknowledged the requirement and noted it could be inferred for
          the <tt>charN_t</tt> types, but not for <tt>char</tt>.</li>
      <li>Tom expressed a belief that support for the <tt>charN_t</tt> types is
          disabled.</li>
      <li>Victor confirmed that is the case.</li>
      <li>Hubert indicated that such conversions could be enabled, but that
          necessary facilities are not currently available at run-time;
          something like ICU or iconv would be needed.</li>
      <li>PBrett suggested that an escape translation could be produced.</li>
      <li>Hubert replied that stateful encodings would require representing
          state.</li>
      <li>Tom asked what the downside is of disabling support for ranges that
          have a mismatched character type as the element type.</li>
      <li>PBrett replied that, ideally, it should be possible to format
          everything.</li>
      <li>Victor agreed with PBrett and stated that formatters for string-like
          types that have a mismatched character element type could be disabled
          and that a specifier to format a range as a string could be
          provided.</li>
      <li>Hubert expressed support for a protocol to opt-in to support of
          string-like types.</li>
      <li>Zach asked if <tt>std::vector</tt> would be considered a string-like
          type.</li>
      <li>Zach expressed support for disabling formatting of ranges with a
          mismatched character element type.</li>
      <li>Victor observed that disabling formatters for mismatched
          <tt>std::string</tt> and <tt>std::string_view</tt> would suffice to
          automatically disable types that derive from them.</li>
      <li>Victor expressed support for distinguishing between string-like and
          non-string-like types.</li>
      <li>Mark noted that support can always be added later for a disabled
          formatter and that disabling these formatters would be an improvement
          over the status quo.</li>
      <li>PBrett agreed and asked Mark if he is willing to author a proposed
          resolution.</li>
      <li>Mark agreed to do so.</li>
      <li><em>[ Editor's note: Mark offered a proposed resolution that is now
          reflected in the LWG issue. ]</em></li>
    </ul>
  </li>
  <li>Tom announced that the next meeting will be 2023-07-26 and that the
      agenda will cover allowances for <tt>$</tt> in identifiers, encoding for
      the proposed <tt>std::contracts::contract_violation::comment()</tt> member
      function, and continued review of of Zach's UTF transcoding paper if a
      new revision becomes available.</li>
</ul>


<h1 id="2023_07_26">July 26th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3145.pdf">WG14 N3145: $ in Identifiers v2</a>:
    <ul>
      <li>Determine whether a corresponding proposal for WG21 is desired.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2811r7">P2811R7: Contract-Violation Handlers</a>:
    <ul>
      <li>Discuss character encoding considerations for the
          <tt>std::contracts::contract_violation::comment()</tt> member
          function.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg3944">LWG 3944: Formatters converting sequences of char to sequences of wchar_t</a>:
    <ul>
      <li>Continue review pending a proposed resolution or related paper.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Corentin Jabot</li>
  <li>Eddie Nolan</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Joshua Berne</li>
  <li>Mark de Wever</li>
  <li>Peter Brett</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Ville Voutilainen</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3145.pdf">WG14 N3145: $ in Identifiers v2</a>:
    <ul>
      <li>Hubert introduced the topic.
        <ul>
          <li>C23 explicitly blessed <tt>$</tt> as an allowed character in
              identifiers as an implementation-defined extension.</li>
          <li>C has traditionally allowed this extension and support for it is
              widely implemented.</li>
          <li><a href="https://wg21.link/p2342">P2342 (For a Few Punctuators More)</a>
              contains additional analysis.</li>
          <li>Up to and including C++20, this has been a conforming extension
              in C++ since <tt>$</tt> in an identifier would be ill-formed.</li>
          <li>In C++20, <tt>$</tt> is a UCN and combines with adjacent
              identifier characters to produce an ill-formed identifier.</li>
          <li>In C++23, <tt>$</tt> is no longer a UCN and adjacency with
              identifier characters now yields two pp-tokens, the second of
              which renders the program ill-formed.</li>
          <li>In C++26, <tt>$</tt> is a member of the basic character set,
              adjacency with identifier characters continues to yield two
              pp-tokens, but the <tt>$</tt> token may be discarded such that
              it is never processed during translation phase 7.</li>
        </ul>
      </li>
      <li>PBrett asked for clarification of what constitutes a conforming
          extension.</li>
      <li>Corentin observed that this extension requires the production of a
          single pp-token when <tt>$</tt> is adjacent to an identifier
          character.</li>
      <li>Corentin stated that sanctioning this allowance in the standard
          would restrict evolution of the language since it would prevent
          use of <tt>$</tt> as an operator.</li>
      <li>Steve noted that the status quo is that all implementations allow
          <tt>$</tt> in identifiers by default, <tt>$</tt> is widely used in
          identifiers, and <tt>$</tt> appears in mangled names.</li>
      <li>Steve stated that compilers are free to issue a diagnostic and
          produce a working executable for source code that is ill-formed
          according to the standard.</li>
      <li>Hubert replied that the concern is with preprocessing; if <tt>$</tt>
          is not explicitly allowed in an identifier by the preprocessor,
          then it is handled as a separate token and the difference is
          observable.</li>
      <li>Hubert stated that issuing a diagnostic only during translation
          phase 7 would be difficult.</li>
      <li>Hubert asserted that wording changes are in order to continue to
          permit existing practice with <tt>$</tt> in identifiers.</li>
      <li>Hubert acknowledged concerns regarding how to word an allowance so
          that new uses of <tt>$</tt> are not restricted.</li>
      <li>Hubert noted that new uses are only problematic if they are not
          surrounded by whitespace.</li>
      <li>Jens suggested the possibility of reverting the adoption of
          <a href="https://wg21.link/p2558r2">P258R2 (Add @, $, and ` to the basic character set)</a>
          for C++26.</li>
      <li>PBrett expressed opposition to doing so since that would contradict
          the direction established in WG14 and codified in C23.</li>
      <li>PBrett stated that this discussion is a good start regarding how to
          move forward.</li>
      <li>Jens opined that the WG14 rationale is not motivating and that he is
          therefore not motivated to follow the same direction in C++.</li>
      <li>Tom noted that there are backward compatibility concerns for some
          platforms due to use of <tt>$</tt> in identifiers in system
          headers.</li>
      <li>Corentin stated that the WG14 direction was to explicitly state that
          it is implementation-defined whether <tt>$</tt> is allowed in an
          identifier.</li>
      <li></b>Poll 1: Whether DOLLAR SIGN is accepted as an identifier start
          and/or identifier continuation character should be explictly
          implementation-defined.</b>
        <ul>
          <li><b>Attendees: 12 (4 abstentions)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">1</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">2</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
          <li><b>SA: I don't think an identifier should be
                 implementation-defined.</b></li>
        </ul>
      </li>
      <li>PBrett stated that the next step would be a proposal to EWG
          acknowledging the guidance here.</li>
      <li>Tom asked for opinions regarding the default modes of current
          compilers being non-conforming.</li>
      <li>Zach replied that all implementations offer an option to disable the
          extension.</li>
      <li>PBrett stated that every implementation is non-conforming in their
          default modes in practice.</li>
      <li>Corentin asserted that implementations should issue warnings for use
          of the extension.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2811r7">P2811R7: Contract-Violation Handlers</a>:
    <ul>
      <li>Joshua introduced the topic:
        <ul>
          <li>SG21 is working on a specification for a contract violation
              handler.</li>
          <li>The proposed <tt>comment()</tt> member function of
              <tt>std::contracts::contract_violation</tt> is intended to return
              a string containing the source code of the violated contract
              predicate.</li>
          <li>The proposed encoding for the returned string is the ordinary
              literal encoding.</li>
        </ul>
      </li>
      <li>Tom expressed support for use of the ordinary literal encoding.</li>
      <li>Tom asked if anything should be specified regarding handling of
          characters that are not encodeable in the ordinary literal
          encoding.</li>
      <li>Corentin agreed with use of the ordinary literal encoding on the
          basis that the text will be used at run-time.</li>
      <li>Steve asked for confirmation that the feature effectively converts a
          source code snippet to text.</li>
      <li>Joshua confirmed.</li>
      <li>Steve suggested that a hand wavy approach similar to that taken for
          <tt>static_assert</tt> is likely necessary except that the string has
          to survive until run-time and we lack a mechanism to communicate the
          encoding.</li>
      <li>Steve stated that the compiler should perform a best effort rendering
          in the target encoding with the understanding that, for example, an
          identifier might not be representable in Latin1.</li>
      <li>Jens observed that is a different operation than stringizing.</li>
      <li>Steve agreed.</li>
      <li>Corentin asked what the anticipated use cases are for the
          <tt>comment()</tt> function.</li>
      <li>Joshua replied that the primary use case is for logging; other use
          cases might involve using the result as a key for a map.</li>
      <li>Joshua asserted that it is not intended to provide source code that a
          programmer might expect to parse.</li>
      <li>Joshua stated that the output is only intended to be sufficient for a
          human to be able to correlate it with the original source code.</li>
      <li>Zach ruminated on the interaction of source encoding and literal
          encoding and how preprocessor stringifying works.</li>
      <li>Jens noted that the <tt>assert</tt> macro is similarly expected to
          embed source code in the output it produces.</li>
      <li>Jens stated that the wording for <tt>assert</tt> does not capture the
          fact that producing the output involves multiple transcoding
          steps.</li>
      <li><em>[ Editor's note: the transcoding steps are the conversion from the
          encoding of the input file
          (<a href="http://eel.is/c++draft/lex.phases#1.1">[lex.phases]p1</a>)
          to the <i>translation character set</i>
          (<a href="http://eel.is/c++draft/lex.charset#1">[lex.charset]p1</a>)
          then to the <i>ordinary literal encoding</i>
          (<a href="http://eel.is/c++draft/lex.charset#8">[lex.charset]p8</a>)
          and then finally, if necessary, to the implementation-defined encoding
          used to write text to the standard error stream
          (<a href="http://eel.is/c++draft/cassert.syn">[cassert.syn]</a>
          via reference to the C standard). ]</em></li>
      <li>Jens observed that, for <tt>comment()</tt>, there is a possibility to
          differentiate these steps; the compiler performs the conversion to the
          ordinary literal encoding and the violation handler can then perform
          additional transcoding as necessary.</li>
      <li>Jens asserted that these are not novel problems.</li>
      <li>Jens observed that non-encodeable characters in string literals are
          ill-formed and that a preprocessor stringize operation that produces
          such a string would likewise be ill-formed.</li>
      <li>Jens posited doing similarly for contracts.</li>
      <li>Corentin stated that doing so makes sense and then described some
          additional encoding options:
        <ul>
          <li>UTF-8 in <tt>char8_t</tt>, though that doesn't improve
              usability.</li>
          <li>implementation-defined.</li>
          <li>ordinary literal encoding with an escaping mechanism for
              non-encodeable characters.</li>
        </ul>
      </li>
      <li>Corentin suggested it is likely best to just let implementors do what
          they think is best.</li>
      <li>PBrett stated that SG21 had strong consensus for the text returned by
          <tt>comment()</tt> being implementation-defined.</li>
      <li>PBrett noted that, since it is implementation-defined, there is no
          need to specify whether the content includes macro expanded text.</li>
      <li>PBrett asserted that it is essential that the encoding be specified
          and expressed support for the current paper direction.</li>
      <li>PBrett agreed that UTF-8 in <tt>char8_t</tt> is an option, but that
          the standard provides few facilities to consume it.</li>
      <li>Hubert noted that, since C does not prohibit non-encodeable characters
          in string literals, the stringize operation suffices for
          <tt>assert</tt> in C.</li>
      <li>Steve stated that it would be very suprising if a <tt>char</tt>-based
          string with an encoding other than the ordinary literal encoding was
          returned; a <tt>char8_t</tt>-based string should be used if a UTF-8
          encoded string is always returned.</li>
      <li><b>Poll 2: The value of std::contract_violation::comment should be a
          null-terminated multi-byte string (NTMBS) in the string literal
          encoding.</b>
        <ul>
          <li><b>Attendees: 12 (1 abstention)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">8</th>
                <th style="text-align:right">3</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Unanimous consensus.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/lwg3944">LWG 3944: Formatters converting sequences of char to sequences of wchar_t</a>:
    <ul>
      <li>PBrett explained that the goal of discussing this issue is to
          determine if we agree with the proposed resolution.</li>
      <li>Victor expressed support for it and stated that it is consistent
          with previous discussions.</li>
      <li>Victor noted a minor markup issue in the proposed wording; the extent
          of the struck text should include the trailing <tt>&gt;</tt>
          character.</li>
      <li><b>Poll 3: Recommend the proposed resolution to LWG3944 "Formatters
          converting sequences of char to sequences of wchar_t" to LWG, after
          fixing the typo.</b>
        <ul>
          <li><b>Attendees: 12</b></li>
          <li><b>No objection to unanimous consent.</b></li>
        </ul>
      </li>
      <li>Mark asked what the next step is for this issue.</li>
      <li>Tom advised sending the proposed resolution to the LWG chair and
          stated that he would work with the LWG chair to get a github issue
          filed to record the SG16 poll.</li>
    </ul>
  </li>
  <li>Tom stated that the next meeting is scheduled for 2023-08-09.</li>
  <li>Zach indicated that he could have a revision of
      <a href="https://wg21.link/p2728">P2728 (Unicode in the Library, Part 1: UTF Transcoding)</a>
      available by then.</li>
  <li>Victor reported that he has a a new revision of
      <a href="https://wg21.link/p2845">P2845: Formatting of std::filesystem::path</a>
      available.</li>
</ul>


<h1 id="2023_08_23">August 23rd, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2909r0">P2909R0: Dude, where’s my char?</a>.
  <li><a href="https://wg21.link/p2728r6">P2728R6: Unicode in the Library, Part 1: UTF Transcoding</a>.
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Fraser Gordon</li>
  <li>Hubert Tong</li>
  <li>Mark de Wever</li>
  <li>Peter Brett</li>
  <li>Robin Leroy</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2909r0">P2909R0: Dude, where’s my char?</a>:
    <ul>
      <li>Much appreciation was expressed for the clever paper title.</li>
      <li><em>[ Editor's note: in later revisions, the R0 title was demoted
          to a sub-title and a new title introduced; "Fix formatting of code
          units as integers". ]</em></li>
      <li>Victor introduced the paper:
        <ul>
          <li>When <tt>std::format()</tt> was introduced, non-portable behavior
              due to the implementation-defined signedness of <tt>char</tt> was
              not intended.</li>
          <li>It is possible that some users expect the signedness to be
              reflected in the output, but most users that are formatting
              character types as integers are intending to expose bit
              patterns.</li>
          <li>This is technically a breaking change.</li>
          <li>This is more LEWG territory, but since it is text related, it
              seemed prudent to collect input from SG16.</li>
        </ul>
      </li>
      <li>PBrett requested that section 2, "Proposal", be expanded to illustrate
          the before/after effects for each of the type options.</li>
      <li>Victor agreed to do so.</li>
      <li>Victor explained that the change increases compatibility with
          <tt>std::printf()</tt> for the impacted type options other than "d";
          the "%d" <tt>std::printf()</tt> conversion specifier always treats its
          argument as a signed type, but the proposed change for the "d" type
          option will always treat <tt>char</tt> as an unsigned type regardless
          of whether it is signed.</li>
      <li>Zach expressed appreciation for symmetry and that the change improves
          support for portable roundtripping behavior.</li>
      <li>Mark acknowledged that the change is a breaking change and asked if
          the intent is to handle this as a DR.</li>
      <li>Victor replied that LEWG will decide that and that he would recommend
          handling this as a DR.</li>
      <li>Mark observed the lack of a feature test macro.</li>
      <li>Victor stated that he could add one.</li>
      <li>Hubert requested that a more descriptive title be used for the
          paper.</li>
      <li>Hubert noted that it is implementation-defined whether
          <tt>wchar_t</tt> is a signed type as well.</li>
      <li>Victor replied that it would be reasonable to treat all <tt>charT</tt>
          types as being unsigned.</li>
      <li>PBrett requested that the paper be updated to explicitly mention
          <tt>wchar_t</tt> as well.</li>
      <li>Hubert expressed some concerns over the proposed change; <tt>char</tt>
          and <tt>wchar_t</tt> do have a signedness and it isn't good for
          programmers to ignore that.</li>
      <li>Victor replied that, for <tt>wchar_t</tt> at least, the concern is not
          as strong since programmers don't tend to use <tt>wchar_t</tt> as an
          integer type as is done with <tt>char</tt>.</li>
      <li>Hubert suggested it might make sense for the "d" type option to
          maintain signedness.</li>
      <li>Victor stated a preference for the signedness handling being
          consistent across the type options.</li>
      <li>Tom noted that <tt>int8_t</tt> could be implemented in terms of
          <tt>char</tt>.</li>
      <li>Hubert noted that most of the changes increase consistency with
          <tt>std::printf()</tt> and stated the improved consistency should be
          extended to all of the integer types.</li>
      <li>PBrett reminded the group that <tt>char</tt> is a distinct type from
          <tt>signed char</tt> and <tt>unsigned char</tt>.</li>
      <li>Zach asserted that it is surprising to get a negative value for a
          <tt>char</tt> type and stated that negative <tt>char</tt> values are
          a wart in the language.</li>
      <li>Hubert noted that
          <a href="https://eel.is/c++draft/basic.fundamental#11">[basic.fundamental]p11</a>
          specifies that <tt>char</tt> is an integer type.</li>
      <li>PBrett asked if an LWG issue should be raised regarding whether
          <tt>int8_t</tt> can use <tt>char</tt> as its designated type.</li>
      <li>Fraser responded that cv-qualified types are also integer types and
          might therefore possibly be used as the designated type unless the
          <tt>int8_t</tt> wording excludes them.</li>
      <li>Hubert noted that cv-qualified types being integer types was a recent
          CWG change.</li>
      <li>PBrett reported that
          <a href="https://eel.is/c++draft/cstdint.syn">[cstdint.syn]</a>
          specifies that <tt>int8_t</tt> must designate a signed integer type
          and that
          <a href="https://eel.is/c++draft/basic.fundamental#1">[basic.fundamental]p1</a>
          doesn't include <tt>char</tt> in its definition of
          <i>signed integer types</i>.</li>
      <li>PBrett stated that we will file a LWG issue to clarify this.</li>
      <li>Tom asked for confirmation of the behavior for integer types other than
          <tt>char</tt> when used with the "o", "x", and "X" type options.</li>
      <li>Victor replied that negative values may be produced.</li>
      <li>Hubert stated that includes <tt>wchar_t</tt> when it is a signed
          type.</li>
      <li>Tom noted that is consistent with the status quo wording.</li>
      <li>Hubert noted that the wording is applicable to <tt>charT</tt>, but not
          to mixed character types.</li>
      <li><b>Poll 1: Modify P2909R0 "Dude, where's my char‽" to maintain
          semi-consistency with printf such that the 'b', 'B', 'o', 'x', and 'X'
          conversions convert all integer types as unsigned.</b>
        <ul>
          <li><b>Attendees: 8 (1 abstention)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">1</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">2</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
          <li><b>SA: I'm not opposed to that direction in principle, but it is
              a deeper change and needs more research.</b></li>
          <li><b>A: I'm concerned about the lack of implementation
              experience.</b></li>
        </ul>
      </li>
      <li><b>Poll 2: Modify P2909R0 "Dude, where's my char‽" to remove the
          change to handling of the 'd' specifier.</b></li>
        <ul>
          <li><b>Attendees: 8 (1 abstention)</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">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">1</th>
              </tr>
            </table>
          </li>
          <li><b>No consensus.</b></li>
          <li><b>SA: That would add a corner case to a corner case; this is
              more LEWG territory and will get discussed there.</b></li>
        </ul>
      </li>
      <li><b>Poll 3: Forward P2909R0 "Dude, where's my char‽", amended with a
          descriptive title, an expanded before/after table, and fixed CharT
          wording, to LEWG with the recommendation to adopt it as a Defect
          Report.</b></li>
        <ul>
          <li><b>Attendees: 8 (1 abstention)</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">2</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Weak consensus.</b></li>
        </ul>
      </li>
      <li>Tom asked if there are any concerns beyond the <tt>std::printf()</tt>
          inconsistencies that would motivate the N and A voters towards
          F/SF.</li>
      <li>No other concerns were raised.</li>
      <li>Hubert expressed unhappiness with the "d" type option direction since
          it won't provide help to those debugging issues related to
          <tt>char</tt> being a signed type.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2728r6">P2728R6: Unicode in the Library, Part 1: UTF Transcoding</a>:
    <ul>
      <li>Zach introduced the changes made in recent revisions:
        <ul>
          <li>The type unpacking mechanism was reworked.</li>
          <li>The <tt>null_sentinel_t</tt> type was moved to the <tt>std</tt>
              namespace.</li>
          <li>A <tt>std::ranges::project_view</tt> was introduced bsaed on SG9
              (Ranges) feedback though this view is likely to be replaced in a
              future revision with a conditionally borrowed
              <tt>transform_view</tt>.</li>
          <li>The <tt>utfN_view</tt>s are now just aliases of a
              <tt>utf_view</tt> class template specialization.</li>
        </ul>
      </li>
      <li>PBrett asked if anyone has new SG16 concerns inspired by the changes
          since R3.</li>
      <li><em>[ Editor's note: SG16's last review of this paper was
          <a href="https://wg21.link/p2728r3">P2728R3</a>
          during the
          <a href="https://github.com/sg16-unicode/sg16-meetings#may-10th-2023">2023-05-10 SG16 meeting</a>.
          ]</em></li>
      <li>No new concerns were raised.</li>
      <li>Tom asked for specific ideas on how to improve presentation in the
          motivation section of the paper to address any lingering concerns from
          reviews of previous revisions.</li>
      <li>PBrett stated that the paper has improved significantly from previous
          revisions</li>
      <li>PBrett volunteered to meet with Zach offline to more thoroughtly
          review that section.</li>
      <li>Fraser asked whether support for the <tt>approximately_sized_range</tt>
          concept proposed by
          <a href="https://wg21.link/p2846">P2846 (<tt>size_hint</tt>: Eagerly reserving memory for not-quite-sized lazy ranges)</a>
          has been considered.</li>
      <li>Zach replied that he has to some extent and noted that there are range
          limits that could be imposed and that might work with that
          feature.</li>
      <li>Fraser asked if the proposal could be retrofitted to support that
          feature as it progresses through the committee.</li>
      <li>Zach replied affirmatively and explained that the <tt>size_hint()</tt>
          member could be conditionally enabled when size information is
          available.</li>
      <li>Hubert requested clarification regarding the request for improvements
          to the motivation section.</li>
      <li>Tom explained that he had received input from multiple people that
          they felt the motivation section was lacking.</li>
      <li>PBrett explained that one of the perceived issues was the lack of
          rationale for the design decisions made and an analysis of
          alternatives considered; for example, during previous SG16
          discussions, vague comments were sometimes made regarding the design
          being motivated by performance concerns, but the performance goals
          and concerns are not reflected in the paper.</li>
      <li>PBrett repeated his earlier claim that recent revisions and the
          refined scope have improved the situation.</li>
      <li>Hubert stated that it sounds like the motivation question might be
          resolved then.</li>
      <li>Hubert suggested that a scope section could be added.</li>
      <li>PBrett reported that, in a recent UK body discussion concerning the
          failure for some papers to attain consensus, observations were made
          that lack of a common understanding of the problem to be solved
          likely contributed to the failure.</li>
      <li>PBrett opined that discussion of earlier revisions of the paper
          exhibited some confusion regarding which problems this paper is
          intended to address.</li>
      <li>Zach stated that he has been working on prototypes that lead to this
          paper for about seven years now and that some of the design
          motivation is influenced by things he learned along the way, but that
          would require some reflection to recall.</li>
      <li>Zach suggested that discussion move towards error handling as
          discussion of that topic was requested in the meeting agenda.</li>
      <li><em>[ Editor's note: Zach was referring to requests made on the SG16
          mailing list. See
          <a href="https://lists.isocpp.org/sg16/2023/08/3930.php">https://lists.isocpp.org/sg16/2023/08/3930.php</a>.
          ]</em></li>
      <li>Robin added some background for the linked
          <a href="http://unicode.org/review/pr-121.html">PR-121 (Recommended Practice for Replacement Characters)</a>
          policies. That policy paper was used to inform the recommendation made
          by the UTC during the
          <a href="https://www.unicode.org/L2/L2008/08253.htm">UTC 116 / L2 213 Joint Meeting held in Redmond, WA from August 11-15, 2008</a>
          in which a
          <a href="https://www.unicode.org/L2/L2008/08253.htm#116-C12">consensus to prefer policy 2</a>
          was established.</li>
      <li>Zach reported having been unaware of PR-121 and that his design
          decisions were guided by what appears in the Unicode Standard.</li>
      <li>Zach summarized the error handling options described by the Unicode
          Standard as:
        <ul>
          <li>terminate</li>
          <li>report an error</li>
          <li>substitute a replacement character.</li>
        </ul>
      </li>
      <li><em>[ Editor's note: the Unicode 15 chapters that discuss handling of
          ill-formed code unit sequences are:
        <ul>
          <li>3.9, Unicode Encoding Forms, U+FFFD Substitution of Maximal
              Subparts.</li>
          <li>5.22, U+FFFD Substitution in Conversion.</li>
        </ul>
         ]</em>
      </li>
      <li>Zach stated that an option to just drop ill-formed code unit sequences
          seems misguided.</li>
      <li>Robin agreed and stated that doing so can lead to security
          issues.</li>
      <li>Zach stated that there are other options to identify encoding errors
          and that he does not want this feature to be made complicated.</li>
      <li>PBrett asserted a need for a feature to just validate that a given
          string can be successfully decoded.</li>
      <li>Zach responded that such a feature was in a previous revision of the
          paper, but that it was removed as part of reducing scope.</li>
      <li>PBrett stated that he actually wants that feature more than he wants
          transcoding support so that input could be proactively rejected.</li>
      <li>Tom expressed sympathy for Zach's perspective but stated a preference
          towards not providing an error handler at all over providing one that
          is unable to handle arbitrary complexity.</li>
      <li>Zach replied that he really only cared to support terminate, throw,
          and substitute as recommended by the Unicode Standard.</li>
      <li>Tom described the error handling approach that JeanHeyd developed for
          his work on
          <a href="https://wg21.link/p1629">P1629 (Standard Text Encoding)</a>;
          it allows for the current iterator to be moved to an error handler
          that manipulates it as necessary and then moves it back; this provides
          the error handler full autonomy.</li>
      <li>Zach replied that such an approach doesn't work for a transcoding
          iterator since exactly one output code unit must be produced; or would
          otherwise require a buffer to be persisted and referenced for later
          outputs.</li>
      <li>Tom expressed gratitude for that response and reported that he had not
          considered the limitations of lazily transcoding within iterator
          operations.</li>
      <li>PBrett provided a brief introduction to the
          <a href="https://github.com/soasis/text">ztd.text</a>
          error handlers.</li>
      <li><em>[ Editor's note: see the error handlers in the header files
          included by
          <a href="https://github.com/soasis/text/blob/main/include/ztd/text/error_handler.hpp">https://github.com/soasis/text/blob/main/include/ztd/text/error_handler.hpp</a>.
          ]</em></li>
      <li>Zach noted that each iterator dereference has to produce the next code
          unit value and that makes it expensive to support anything other than
          substitution of a single code point.</li>
      <li>PBrett asked if more design space options are opened by considering
          views rather than iterators.</li>
      <li>Zach replied that the iterators are stateful in either case.</li>
      <li>Zach stated that he would be ok with dropping the error handler in
          favor of only doing substitution and noted that the error handler can
          only be specified when the iterators are used directly; the views
          don't support providing an error handler.</li>
      <li>Tom asked Hubert if his previously expressed interest in exposing the
          type unpacking behavior has been satisfied.</li>
      <li>Hubert did not recall his previous interest.</li>
      <li>Tom explained his recollection; that Hubert wanted to be able to take
          advantage of the unpacking behavior when writing adapters to be used
          in range pipelines.</li>
      <li>Zach stated that the concepts in the paper might need to be refined a
          bit but that he has a test that does that.</li>
      <li>Tom requested that an example be added to the paper.</li>
      <li>Hubert suggested that the motivation section be updated to explain
          that functionality as well.</li>
    </ul>
  </li>
  <li>Tom reported that the next meeting will be 2023-09-13 and that likely
      agenda items include continued review of P2728R6 and initial review of
      <a href="https://wg21.link/p1729r2">P1729R2 (Text Parsing)</a>.</li>
</ul>


<h1 id="2023_09_13">September 13th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p2845r3">P2845R3: Formatting of std::filesystem::path</a>:
    <ul>
      <li>Continue review.</li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2728r6">P2728R6: Unicode in the Library, Part 1: UTF Transcoding</a>:
    <ul>
      <li>Continue review.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Corentin Jabot</li>
  <li>Eddie Nolan</li>
  <li>Fraser Gordon</li>
  <li>Hubert Tong</li>
  <li>Jens Maurer</li>
  <li>Nathan Owen</li>
  <li>Robin Leroy</li>
  <li>Steve Downey</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
  <li>Zach Laine</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li><a href="https://wg21.link/p2845r3">P2845R3: Formatting of std::filesystem::path</a>:
    <ul>
      <li><em>[ Editor's note: D2845R3 was the active paper under discussion at the telecon.
          The agenda and links used here reference P2845R3 since the links to the draft paper were ephemeral.
          The published document may differ from the reviewed draft revision.
          ]</em></li>
      <li>Tom noted that SG16 previously reviewed P2845R0 and that the current
          revision addresses prior review feedback.</li>
      <li>Victor provided an introduction:
        <ul>
          <li>The recent revisions correct some minor mistakes.</li>
          <li>The proposed default format now produces a non-quoted non-escaped
              representation.</li>
          <li>If the format specifier includes the <tt>?</tt> option, then a
              quoted escaped representation is produced.</li>
          <li>The
              <a href="https://github.com/fmtlib/fmt">{fmt} library</a>
              had previously implemented the behavior proposed in P2845R0 but
              was recently changed to implement the behavior introduced in
              P2845R2; this was a breaking change that impacted a few
              users.</li>
        </ul>
      </li>
      <li>Eddie pointed out an incorrect word choice in section 6, Proposal;
          "loose" is used where "lose" is intended.</li>
      <li>Victor stated that the output shown for the first lone surrogate
          example in section 6, Proposal, might be incorrect and that he needs
          to check if a <tt>\x</tt> escape should be produced instead of the
          <tt>\u</tt> escape currently presented; the intent is for the
          behavior to match what is specified in
          <a href="https://eel.is/c++draft/format.string.escaped">[format.string.escaped]</a>.</li>
      <li><b>Poll 1: Forward P2845R2, Formatting of std::filesystem::path, to LEWG with a recommended target of C++26.</b>
        <ul>
          <li><b>Attendees: 9 (1 abstention)</b></li>
          <li>
            <table>
              <tr>
                <th style="text-align:right">SF</th>
                <th style="text-align:right">F</th>
                <th style="text-align:right">N</th>
                <th style="text-align:right">A</th>
                <th style="text-align:right">SA</th>
              </tr>
              <tr>
                <th style="text-align:right">5</th>
                <th style="text-align:right">2</th>
                <th style="text-align:right">1</th>
                <th style="text-align:right">0</th>
                <th style="text-align:right">0</th>
              </tr>
            </table>
          </li>
          <li><b>Strong consensus.</b></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="https://wg21.link/p2728r6">P2728R6: Unicode in the Library, Part 1: UTF Transcoding</a>:
    <ul>
      <li>Tom reminded the group that our purpose as a study group is to assist
          paper authors in producing a proposal that has the best possible
          chance of passing review in other groups and, ultimately, an adoption
          poll in a plenary session.</li>
      <li>Tom stressed that questions asked during discussion likely reflect
          some lack of clarity in the paper and should therefore inspire
          additional edits, not just immediate responses.</li>
      <li>Tom listed the topics for discussion as presented in the
          <a href="https://lists.isocpp.org/sg16/2023/09/3955.php">previously communicated agenda</a>:
        <ul>
          <li>Continued review of error handling.</li>
          <li>Opportunities for simplification; whether <tt>std::uc::format</tt>
              is still needed.</li>
          <li>How the proposed features fit with the bigger picture and vision
              for future library proposals.</li>
        </ul>
      </li>
      <li>Zach summarized some other recent reviews:
        <ul>
          <li>SG9 has reviewed the paper three times and plans to review it at
              least one more time.</li>
          <li>SG9 has provided some feedback that has not yet been incorporated
              in the paper.</li>
        </ul>
      </li>
      <li>Zach provided an overview of the proposed error handling:
        <ul>
          <li>The error handler receives an unspecified diagnostic message that
              programmers can use as they please.</li>
          <li>The default error handler ignores the diagnostic message and
              returns a replacement character.</li>
        </ul>
      </li>
      <li>Zach stated that the error handling approach used in JeanHeyd's work
          doesn't fit into the iterator model.</li>
      <li>Zach said he does not have strong opinions about the error handler
          and suggested it could be removed for now and added back later if
          needed.</li>
      <li>Steve noted that transliteration is a use case for error handlers
          that allow multiple characters to be substituted for a
          non-translateable character.</li>
      <li>Steve acknowledged that support for multi-character substitution
          would require a buffer that would make iterators larger and more
          complicated.</li>
      <li>Corentin expressed confusion regarding the transliteration example
          since the proposed functionality is specific to UTF encodings.</li>
      <li>Corentin suggested implementing transliteration as a layered view
          adapter.</li>
      <li>Corentin stated that there are few good options beyond a single
          replacement character approach and that this approach is conforming,
          implementable, and useful.</li>
      <li>Victor observed that the error handling interface treats all errors
          the same and that there is no distinction between different kinds of
          errors.</li>
      <li>Zach responded that there are a fixed number of error possibilities
          and that a set of error codes would be isomorphic to the set of
          messages that are passed in the reference implementation.</li>
      <li>Tom asked Zach if he has a strong preference.</li>
      <li>Zach replied that his preference is to just substitute a replacement
          character and otherwise ignore any errors.</li>
      <li>Tom expressed a belief that there are other reasonable error handling
          possibilities, but that a concrete proposal should be offered before
          trying to engage further on such discussion.</li>
      <li>Jens noted that passing an error message creates an
          internationalization concern and expressed a preference against a
          message based interface.</li>
      <li>Jens pondered the plausible options for reacting to an error:
        <ul>
          <li>The substitution approach is easily understood and Unicode
              provides a recommendation for how to perform them.</li>
          <li>Throwing an exception is easily understood and works with ranges
              and iterators.</li>
          <li>Since the error handler is not given access to the ill-formed
              code unit sequence, there is little context for doing anything
              else useful.</li>
        </ul>
      </li>
      <li>Zach indicated that he would be fine with replacing the
          <tt>std::string_view</tt> parameter with an enumeration.</li>
      <li>Zach noted that substitution of a different replacement character
          would not be inline with Unicode recommendations.</li>
      <li>Jens stated that there is no universal right answer for error
          handling for all programs; throwing an exception could be the right
          choice for one while aborting could be the right choice for
          another.</li>
      <li>Zach suggested that <tt>utf_iterator</tt> could be used to single
          step through the input and noted that it provides access to the
          underlying sequence.</li>
      <li>Zach stated that trying to provide a tool that handles every
          situation seems unnecessary.</li>
      <li>Jens asked if the paper has an example that demonstrates single
          stepping through an input sequence with access to the underlying
          code unit sequence.</li>
      <li>Tom commented that such an example would be a great addition to the
          paper.</li>
      <li>Zach asked for a poll to remove the error handler.</li>
      <li>Steve seconded Jens' preference to not use a stringly-typed error
          message.</li>
      <li>Steve expressed tenuous consent for removal of the error handler
          based on the discussion.</li>
      <li>Steve summarized the design requirements; there is one error handling
          mode that we want for sure, and a few others that we might want
          rarely.</li>
      <li>Steve expressed a desire for more examples in the paper.</li>
      <li>Corentin stated that views are not designed for error handling;
          they are designed for composition.</li>
      <li>Corentin outlined a design approach for a different feature; a view
          that iterates over ill-formed code unit sequences.</li>
      <li>Corentin pondered which replacement policy should be used.</li>
      <li>Zach replied that Unicode specifies the recommended replacement
          policy.</li>
      <li>Jens requested that the paper explicitly reference that policy.</li>
      <li>Zach responded that it already does.</li>
      <li><em>[ Editor's note:
          section 5.4, "Add the transcoding iterator template", has a paragraph
          that states:</em>
          <blockquote class="quote">
          The number and position of the error handler invocations should use the
          “substitution of maximal subparts” approach described in Chapter 3 of the
          Unicode standard.
          </blockquote>
          <em>]</em></li>
      <li>Hubert asked if formal wording is available.</li>
      <li>Zach replied that there is some pseudo wording, but no real wording
          yet.</li>
      <li>Eddie observed that removal of the error handling interface would
          require use of a for statement for even minimal error handling.</li>
      <li>Eddie posited a use case that requires counting the number of errors
          encountered and noted that it could be implemented using the proposed
          design with the caveat that it would require global state since error
          handler objects are not persistent.</li>
      <li>Zach acknowledged such use cases, but characterized them as examples
          of corner cases that are not frequently needed.</li>
      <li>Hubert stated that he does not see a reason to prohibit the easy
          error handling cases and opined that removal of the error handler
          would be an over reaction.</li>
      <li>Tom noted that the error handler is stateless; an object of the error
          handler is constructed on demand for each error and since the error
          handler is not passed details of the error encountered, error handling
          is severely constrained.</li>
      <li>Jens charaterized the lack of persistence of an error handling object
          as a design defect; global state should not be required for Eddie's
          example.</li>
      <li>Zach stated that the discussion has made it clear that we don't have
          a good grasp of the design that we want.</li>
      <li>Corentin pondered how error handling in the middle of a lazy algorithm
          should be performed and suggested that may be a question for SG9.</li>
      <li>Corentin stated that there are currently no standard views that
          throw.</li>
      <li>Corentin suggested that views might not be the appropriate utility to
          use to sanitize input.</li>
      <li>Corentin noted that a requirement to maintain state might make it
          difficult to match range complexity requirements.</li>
      <li>Corentin advised using a view that operates on code units to analyze
          code units.</li>
      <li>Zach agreed with Corentin's comments and stated that the proposal
          does not support custom error handling for views for exactly those
          reasons.</li>
      <li>Tom suggested meeting with SG9 to discuss error handling in range
          pipelines.</li>
      <li>Zach agreed to do so.</li>
      <li>Eddie noted that exceptions are the only way to alter the control
          flow in range pipelines.</li>
      <li>Tom agreed and stated that iterator operations don't provide an option
          other than throwing exceptions.</li>
      <li>Eddie indicated that those limitations make him less inclined to
          support custom error handling.</li>
      <li>Jens acknowledged that existing standard views might not throw
          exceptions directly, but noted that views that accept a callable, like
          <tt>std::ranges::transform_view</tt> allow an exception to be
          conditionally thrown based on the input in order to break the pipeline
          processing.</li>
      <li>Jens concurred with having SG9 weigh in and perhaps poll error
          handling for ranges.</li>
      <li>Jens requested an example of how error checking and handling could be
          performed using the proposed iterators in a for statement so that he
          could better determine how programmers could provide their own
          exception throwing view.</li>
      <li>Zach provided an example in the chat.
<pre style="display:inline"><tt>
auto v = my_view();
for (auto it = v.begin(); it != v.end(); ++it) {
  if (is_replacement_character(*it)) ...
}
</tt></pre>
      </li>
      <li>Jens pointed out that the example doesn't differentiate between a
          substitution character in the input vs a substitution made due to an
          ill-formed code unit sequence.</li>
      <li>Zach replied that doing so would require inspecting and comparing
          code units.</li>
      <li>Hubert opined that we don't have a great story here if we're going to
          be telling programmers to figure this out themselves.</li>
      <li>Zach suggested that we don't have a good understanding of the needs
          right now, but stated improvements can be made later.</li>
      <li>Tom expressed skepticism that error handling could be added later
          since the addition of a template parameter, even one with a default
          argument, would break passing these class templates as template
          template parameters.</li>
      <li>Jens expressed a belief that the standard reserves the right to make
          such additions.</li>
      <li>Zach agreed that such changes would constitute an ABI break.</li>
      <li>Hubert agreed that it seems that we don't know exactly what we
          want.</li>
      <li>Jens expressed skepticism that there aren't compelling use cases for
          custom error handling and suggested that a more complete design that
          addresses those use cases might subsume the use cases met with what
          is proposed.</li>
      <li>Jens stated that his personal approach is to never accept bad data
          provided via a network since bad data can lead to security
          vulnerabilities.</li>
      <li>Zach suggested that a good solution might be to wrap the for statement
          that single steps the character decoding in a convenient interface for
          users.</li>
      <li>Tom advised that we not poll this topic for now and that we move on to
          other topics such as whether the <tt>std::uc::format</tt> enumeration
          is still needed.</li>
      <li>Zach stated the enumeration is no longer needed and can be
          removed.</li>
      <li>Zach backtracked slightly and stated that he needs to implement that
          removal to confirm that is the case.</li>
      <li>Jens noted that the enumeration is isomorphic to the three UTF code
          unit types.</li>
      <li>Tom directed the discussion towards another topic; how the proposed
          functionality fits in with other features we expect to provide in the
          future.</li>
      <li>Corentin stated that the requirements are different with respect to
          JeanHeyd's work on
          <a href="https://github.com/soasis/text">ztd.text</a>
          and
          <a href="https://wg21.link/p1629">P1629 (Transcoding the 🌐 - Standard Text Encoding)</a>.</li>
      <li>Corentin noted that Zack's proposed features are suitable for
          freestanding and can therefore run on a toaster; that isn't the case
          for JeanHeyd's work.</li>
      <li>Corentin expressed support for having multiple solutions, particularly
          since JeanHeyd's work cannot reasonably be implemented to work with
          the same constraints.</li>
      <li>Jens recalled that JeanHeyd's work is targeting WG14 and C
          interfaces.</li>
      <li>Tom replied that JeanHeyd has proposals targeting both WG14 and WG21
          and that the WG14 proposal provides low level functionality needed
          for his WG21 proposal.</li>
      <li><em>[ Editor's note: JeanHeyd's related proposal for WG14 is
          <a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3095.htm">N3095 (Restartable Functions for Efficient Character Conversion, r11)</a>.
          ]</em></li>
      <li>Jens observed that Zach's proposal is limited to support for the
          well-defined UTF encodings and avoids the complications of table
          lookups and such that come with support for arbitrary encodings.</li>
      <li>Tom asked Zach to confirm that there is no known reason that his
          proposal should not be implementable for freestanding
          implementations.</li>
      <li>Zach confirmed.</li>
      <li>Jens noted that there are no system calls involved.</li>
      <li>Zach reported that he spent time looking at how ztd.text is
          implemented and how the features could be integrated and that, the
          more he discussed with Tim Song, the more it looked like integration
          just wasn't feasible.</li>
      <li>Zach stated that his proposal implements lazy algorithms where as
          JeanHeyd's work implements eager transformations that can optimize
          based on knowledge of the destination.</li>
      <li>Zach said he could not find a reasonable way to make these compatible
          or to implement one in terms of the other.</li>
      <li>Tom claimed it is ok if these features are complementary without
          being integrated.</li>
    </ul>
  </li>
  <li>Tom stated that the next meeting is scheduled for 2023-09-27 and that the
      anticipated agenda will include an initial review of
      <a href="https://wg21.link/p1729r2">P1729R2 (Text Parsing)</a>.</li>
  <li>Tom asked for opinions regarding what else should be discussed before
      we're ready to poll forwarding this paper.</li>
  <li>Corentin replied that we could work on improving the presentation in the
      paper for LEWG.</li>
  <li>Corentin noted that LEWG is likely to return the paper to SG16 for any
      Unicode questions not answered in the paper.</li>
  <li>Hubert suggested that LEWG review the design before substantial effort is
      expended on formal wording.</li>
</ul>


<h1 id="2023_09_27">September 27th, 2023</h1>

<h2>Draft agenda:</h2>

<ul>
  <li><a href="https://wg21.link/p1729r2">P1729R2: Text Parsing</a>:
    <ul>
      <li>Initial review.</li>
    </ul>
  </li>
</ul>

<h2>Attendees:</h2>

<ul>
  <li>Eddie Nolan</li>
  <li>Elias Kosunen</li>
  <li>Fraser Gordon</li>
  <li>Nathan Owen</li>
  <li>Peter Brett</li>
  <li>Robin Leroy</li>
  <li>Tom Honermann</li>
  <li>Victor Zverovich</li>
</ul>

<h2>Meeting summary:</h2>

<ul>
  <li>Tom announced that Steve Downey has agreed to take on a SG16 co-chair
      role and will likely participate in a SG16 meeting chair rotation.</li>
  <li>PBrett stated that he might have less time available for SG16 meetings
      in the near future due to commute changes.</li>
  <li>Tom reported that an in-person meeting for SG16 is not planned for
      Kona.</li>
  <li>PBrett noted that SG21 (contracts) is likely to reduce both his and
      Tom's availability during the Kona meeting.</li>
  <li>Fraser asked if SG16 is impacted by the recent decision to disallow ISO
      and INCITS from hosting joint meetings.</li>
  <li>PBrett responded that it is not.</li>
  <li><a href="https://wg21.link/p1729r2">P1729R2: Text Parsing</a>:
    <ul>
      <li>Elias offered an introduction:
        <ul>
          <li>SG16 reviewed P1729R0 during the in-person meeting in
              Cologne.</li>
          <li>P1729R1 was reviewed by LEWG-I soon after, but activity then
              stalled until recently.</li>
          <li>There have been a lot of changes.</li>
          <li><tt>std::scan</tt> is the parsing analog to
              <tt>std::format</tt>.</li>
        </ul>
      </li>
      <li>Elias proceded with presenting the paper.</li>
      <li>PBrett pointed out an error in the comments in the example code in
          section 3.1, "Basic example";
          <tt>result.begin()</tt> should be <tt>result-&gt;begin()</tt>.</li>
      <li>Elias reported that that error has already been corrected in an R3
          draft.</li>
      <li>PBrett asked whether <tt>begin()</tt> reflects the start of the
          parsed range or the start of the remaining text.</li>
      <li>Elias replied that it reflects the unparsed remainder.</li>
      <li>Fraser asked why the text to be parsed is passed before the format
          string.</li>
      <li>Elias replied that the order is consistent with <tt>scanf()</tt>.</li>
      <li>Tom observed that the dereference of <tt>result</tt> in the example
          code in section 3.5, "Alternative error handling", is unconditional
          and would presumably result in some kind of bad behavior if the scan
          was not successful.</li>
      <li>Elias confirmed that would result in undefined behavior, noted that
          an exception would be thrown if <tt>result.value()</tt> was used
          instead, and stated that the null-coalesing example avoids the bad
          behavior.</li>
      <li>Elias stated that the example should probably be updated.</li>
      <li>Elias presented 3.6, "Scanning an user-defined type" and stated that,
          with regard to encoding, his implementation assumes UTF-8, but that
          doing so is probably not acceptable for the standard.</li>
      <li>Victor replied that most of the matching against the format string is
          encoding agnostic and just needs to match code units.</li>
      <li>Victor noted that encoding issues are relevant for cases that involve
          locale.</li>
      <li>Victor asserted that the same encoding approach should be used as for
          <tt>std::format</tt>; use the ordinary literal encoding.</li>
      <li>PBrett reported that other encodings, such as EUC-KR, are still widely
          used in some regions.</li>
      <li>Elias presented 6.2, "<tt>scanf</tt>-like <tt>[character set]</tt>
          matching", a future extension to support matching a range of
          characters and asked about the potential to unintentionally close off
          the possibility of future support for such extensions if they are not
          provided up front.</li>
      <li>Tom replied that he didn't have any such concerns.</li>
      <li>Tom stated that this is regex-like behavior that could be layered on
          in a different manner.</li>
      <li>PBrett expressed a desire for such a feature in order to ease
          migration from <tt>scanf()</tt>.</li>
      <li>PBrett noted that matching a range could be locale dependent.</li>
      <li>Victor asserted that feature additions should be motivated by usage
          and noted that <tt>std::format()</tt> does not provide replacements
          for all features in <tt>printf()</tt>.</li>
      <li>Eddie asked if a range of characters might be sensitive to encoding;
          for example, the meaning of the range <tt>[A-Z]</tt> could potentially
          be different for EBCDIC vs ASCII.</li>
      <li>Tom suggested revisiting such concerns with locale in mind at a later
          time.</li>
      <li>Tom noted that character set ranges are locale sensitive in utilities
          like <tt>grep</tt>.</li>
      <li>Tom directed discussion back to section 4.2, "Format strings", and
          stated that the use of <tt>std::isspace()</tt> to scan whitespace is
          problematic because it is only able to recognize whitespace characters
          that are encoded as a single code unit.</li>
      <li>Tom asked Victor to confirm that a definition of whitespace characters
          was not required for <tt>std::format()</tt>.</li>
      <li>Victor confirmed.</li>
      <li>Tom suggested that, if the associated literal encoding is a standard
          unicode encoding form, then the set of whitespace characters should be
          defined to match one of the Unicode whitespace definitions and that
          the set is otherwise implementation-defined.</li>
      <li>Elias noted that Unicode specifies a lot of whitespace characters and
          wondered how surprising recognizing them might be.</li>
      <li>Robin stated that Unicode provides multiple whitespace character
          definitions for use in various contexts via the <tt>White_Space</tt>
          and <tt>Pattern_White_Space</tt> character properties.</li>
      <li>Robin noted that <tt>Pattern_White_Space</tt> has the advantage of
          being immutable and that it includes some invisible characters that
          should be ignored.</li>
      <li>Robin explained that <tt>Pattern_White_Space</tt> is intended to be
          used for the specification of programming languages and that Unicode
          offers a recommendation in
          <a href="https://www.unicode.org/reports/tr31/tr31-39.html">UAX #31 of Unicode 15.1</a>.</li>
      <li><em>[ Editor's note: See
          <a href="https://www.unicode.org/reports/tr31/tr31-39.html#Whitespace">section 4.1, "Whitespace"</a>
          and, in particular,
          <a href="https://www.unicode.org/reports/tr31/tr31-39.html#R3a">conformance requirement UAX31-R3a</a>.
          ]</em></li>
      <li>Tom provided a Unicode utilities link that lists all the characters
          with <tt>Pattern_White_Space=Yes</tt>.
        <ul>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[:Pattern_White_Space=Yes:]">https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[:Pattern_White_Space=Yes:]</a></li>
        </ul>
      </li>
      <li>PBrett lamented the "null" names for the C0 and C1 control
          characters.</li>
      <li>Robin filed an issue to correct the display names.
        <ul>
          <li><a href="https://github.com/unicode-org/unicodetools/issues/542">The UnicodeSet utility should show Name_Alias in the absence of Name</a></li>
        </ul>
      </li>
      <li><em>[ Editor's note: Following the meeting, Robin shared additional
          details regarding the categorization of whitespace in the Unicode
          Standard. Even this is an incomplete list.
        <ul>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7BZs%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that are categorized as space separators</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7BName%3D%2F%5CbSPACE%5Cb%2F%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that are called spaces</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7BWhite_Space%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that are white space</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7BPattern_White_Space%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that should be treated as white space in machine-readable syntaxes</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7BLine_Break%3DSPACE%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that behave like space for line breaking</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7Bbc%3Dws%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that behave like space for bidirectional ordering</a></li>
          <li><a href="https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5Cp%7Bwb%3DWSeg_Space%7D&g=General_Category&i=White_Space%2C+Pattern_White_Space">Things that behave like space for word separation</a></li>
        </ul>
        ]</em>
      </li>
      <li>Tom asked for a clarification in the example in section 4.3.2,
          "Fill and align"; if the format string for <tt>rK</tt> was changed
          to <tt>"**42*"</tt> would that result in an error like in the
          <tt>rI</tt> example?</li>
      <li>Elias replied affirmatively.</li>
      <li>Tom suggested it might be worth adding an additional example to make
          that explicit.</li>
      <li>Elias asked what the behavior should be for input that is invalidly
          encoded and stated that he had planned to propose substitution with
          a replacement character, but that approach is problematic for output
          types with reference semantics like <tt>std::string_view</tt>.</li>
      <li>Tom asked facetiously why the input wasn't sanitized before being
          passed to <tt>std::scan</tt>.</li>
      <li>Tom noted that this is a basic error handling question.</li>
      <li>Victor stated that substituting a replacement character doesn't work
          well in general since it can't be matched by most of the type
          specific scanners.</li>
      <li>Victor suggested treating invalidly encoded input as an error such
          that an unsuccessful scan result is returned.</li>
      <li>PBrett noted that ill-formed sequences could just be passed through
          when scanning for string input.</li>
      <li>Tom asked how the scanner would know when to stop scanning.</li>
      <li>PBrett replied that the replacement character could be handled as a
          character that doesn't match any other character.</li>
      <li>Tom quipped, so it's a NaN.</li>
      <li>PBrett agreed.</li>
      <li>Robin suggested treating such substituted characters as the unknown
          character, U+FFFF, with regard to Unicode properties and shared a
          link that lists those properties.
        <ul>
          <li><a href="https://util.unicode.org/UnicodeJsps/character.jsp?a=FFFF&B1=Show">https://util.unicode.org/UnicodeJsps/character.jsp?a=FFFF&B1=Show</a></li>
        </ul>
      </li>
      <li>Elias expressed concern about the overhead imposed by always
          validating the encoding of the input, but noted that passing
          ill-formed sequences through means that errors are sometimes caught
          and sometimes not.</li>
      <li>Eddie expressed a desire for input to be sanitized to avoid having to
          worry about the consequences otherwise.</li>
      <li>PBrett observed that, historically, we have required input to be
          sanitized and noted that validating the input is helpful to avoid
          undefined behavior.</li>
      <li>PBrett summarized the options available; make the behavior
          well-defined, make it undefined, or, perhaps, categorize it as
          erroneous though we don't yet know how to apply that concept to the
          standard library.</li>
      <li><em>[ Editor's note: "Erroneous behavior" is a concept recently
          discussed within WG21 in the context of
          <a href="https://wg21.link/p2795">P2795 (Erroneous behaviour for uninitialized reads)</a>.
          ]</em></li>
      <li>Elias noted that scanners written for user-defined types are unlikely
          to perform encoding validation, but that we could encourage authors to
          delegate scanning back to <tt>std::scan</tt> as demonstrated in
          section 3.6, "Scanning an user-defined type".</li>
      <li>Robin reported that Unicode does have a conformance requirement that
          ill-formed input not be treated as a character and directed the group
          to
          <a href="https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf#G54355">conformance clause C.10 in chapter 3 of Unicode 15</a>.
          <blockquote class="quote">
            When a process interprets a code unit sequence which purports to be
            in a Unicode character encoding form, it shall treat ill-formed code
            unit sequences as an error condition and shall not interpret such
            sequences as characters.
          </blockquote>
      </li>
      <li>PBrett interpreted the clause as motivation for erroneous
          behavior.</li>
      <li>Robin asked whether erroneous behavior is similar to Ada's concept of
          bounded errors and provided a link to
          <a href="http://www.ada-auth.org/standards/22aarm/html/AA-1-1-5.html">section 1.1.5, "Classification of Errors" in the Ada 2022 standard</a>.</li>
      <li><em>[ Editor's note: "erroneous behavior" as recently used in WG21
          does appear to correlate well with Ada's "bounded errors". Note that
          Ada's "erroneous execution" corresponds to the C and C++ notion of
          "undefined behavior". ]</em></li>
      <li>Tom provided a brief overview of the recent history of erroneous
          behavior and its proposed use for reads of uninitialized
          variables.</li>
      <li><em>[ Editor's note: Robin shared a link to
          <a href="http://www.ada-auth.org/standards/22aarm/html/AA-13-9-1.html#p9">section 13.9.1, "Data Validity", paragraph 9 in the Ada 2022 standard</a>
          and its discussion of handling of objects with invalid
          representations; such cases might arise due to lack of
          initialization. ]</em></li>
      <li>PBrett asked if there is a way to scan a single code point.</li>
      <li>Elias replied that there is in his reference implementation but that
          it is provided via a distinct <tt>scanner</tt> specialization for a
          <tt>code_point</tt> type.</li>
      <li>Elias suggested that it might be desirable to support transcoding of
          <tt>charN_t</tt>-based types in the future.</li>
      <li>PBrett noted that scanning of <tt>charN_t</tt>-based types does not
          involve ambiguous encoding.</li>
      <li>Victor expressed uncertainty regarding how to handle such transcoding
          when the corresponding literal encoding isn't a standard Unicode
          encoding form.</li>
      <li>Elias stated that a programmer can handle such concerns on their own,
          but only for a user-defined type since they would not be permitted
          to specialize <tt>std::scanner</tt> for the <tt>charN_t</tt>
          types.</li>
      <li>Elias explained that locale support is opt-in the same as it is for
          <tt>std::format</tt> and that the classic locale is used by
          default.</li>
      <li>Tom pondered whether it would be desirable to recognize input using
          both the specified locale and the classic locale.</li>
      <li>PBrett expressed strong opposition.</li>
      <li>Tom realized use of multiple locales doesn't work at all because
          recognition of characters used for, e.g., thousands separators and
          decimal points would be ambiguous.</li>
      <li>PBrett requested the addition of an example to the paper to
          demonstrate explicit use of a locale.</li>
      <li>PBrett asserted that it is a programmer requirement to ensure that
          input is correctly encoded for the specified locale.</li>
      <li>Elias directed attention to section 4.3.5, "Localized (L)", and asked
          whether a misplaced grouping separator should result in an error.</li>
      <li>Elias indicated that the proposed behavior is consistent with
          iostreams.</li>
      <li>Victor cautioned against being innovative and opined that existing
          practice should be followed.</li>
      <li>Victor noted that implementation of a relaxed scanner should not be
          difficult when needed.</li>
      <li>Tom noted the discussion of alternative options for interpretation of
          field width units in section 4.3.4, "Width and precision" and asked
          for motivating reasons to consider options that differ from
          <tt>std::format</tt>.</li>
      <li>Elias replied that the proposed behavior differs from
          <tt>std::scanf()</tt>.</li>
      <li>Tom asked whether the message strings described in section 4.6,
          "Error handling" require translation or localization.</li>
      <li>Elias replied that they are intended for use with
          <tt>std::exception</tt> and therefore target programmers rather than
          end users.</li>
    </ul>
  </li>
  <li>Tom stated that the next meeting is scheduled for October 11th and that
      an agenda is still to be determined.</li>
</ul>


</body>
