<div dir="ltr"><h1 class="inbox-inbox-title" style="text-align:center;margin-bottom:0.2em;font-family:&quot;Times New Roman&quot;">Study Group 16 <code>std::text</code> Technical Direction</h1><div id="inbox-inbox-table-of-contents" style="font-family:&quot;Times New Roman&quot;;font-size:medium"><h2>Table of Contents</h2><div id="inbox-inbox-text-table-of-contents"><ul><li><a href="#org8834a1a">1. Abstract</a></li><li><a href="#org666258c">2. Design Space and current decisions around <code>std::text</code></a><ul><li><a href="#orga44a941">2.1. Areas of broad agreement</a></li><li><a href="#org5ac55b1">2.2. Areas of Discussion</a></li></ul></li><li><a href="#org8f98040">3. Near Term Plans</a></li><li><a href="#org931780b">4. 2019</a></li></ul></div></div><div id="inbox-inbox-outline-container-org8834a1a" class="inbox-inbox-outline-2" style="font-family:&quot;Times New Roman&quot;;font-size:medium"><h2 id="inbox-inbox-org8834a1a"><span class="inbox-inbox-section-number-2">1</span> Abstract</h2><div class="inbox-inbox-outline-text-2" id="inbox-inbox-text-1"><p>SG16 intends to produce a proposal for a vocabulary type to handle Unicode text and associated Unicode algorithms, tentatively named <code>std::text</code> for C++ 23. No significant text handling facility is targeted for C++ 20.</p></div></div><div id="inbox-inbox-outline-container-org666258c" class="inbox-inbox-outline-2" style="font-family:&quot;Times New Roman&quot;;font-size:medium"><h2 id="inbox-inbox-org666258c"><span class="inbox-inbox-section-number-2">2</span> Design Space and current decisions around <code>std::text</code></h2><div class="inbox-inbox-outline-text-2" id="inbox-inbox-text-2"></div><div id="inbox-inbox-outline-container-orga44a941" class="inbox-inbox-outline-3"><h3 id="inbox-inbox-orga44a941"><span class="inbox-inbox-section-number-3">2.1</span> Areas of broad agreement</h3><div class="inbox-inbox-outline-text-3" id="inbox-inbox-text-2-1"><ul class="inbox-inbox-org-ul"><li>There needs to be a type that which maintains the invariants of well formed Unicode allowing for text manipulation, an analogue of <code>std::string</code>.</li><li>There needs to be an associated view type, <code>std::text_view</code>, an analogue of <code>std::string_view</code></li><li>The type <code>char8_t</code>, although useful for distinguishing Unicode string literals, does not guarantee well-formed UTF-8.</li><li>The type <code>std::text</code> will not have the fat interface <code>std::string</code> does.</li><li>Execution character encoding and compile time character encoding are not changing, however <code>std::text</code> will be independent of that.</li><li>Current locale support is insufficient for implementing Unicode algorithms, such as tailoring, and probably not worth attempting to extend to support Unicode algorithm needs.</li><li>The default view of text as a sequence is NOT code units.</li><li>The type <code>std::text</code> will support allocators.</li><li>It will not be incorrect to use <code>std::text</code> instead of <code>std::string</code>, however there may be performance penalties.</li><li>The code unit sequence for <code>std::text</code> can be null terminated cheaply, and this may be useful for OS APIs.</li><li>UTF-8 is a safe choice for transporting Unicode across naive C and C++.</li></ul></div></div><div id="inbox-inbox-outline-container-org5ac55b1" class="inbox-inbox-outline-3"><h3 id="inbox-inbox-org5ac55b1"><span class="inbox-inbox-section-number-3">2.2</span> Areas of Discussion</h3><div class="inbox-inbox-outline-text-3" id="inbox-inbox-text-2-2"><ul class="inbox-inbox-org-ul"><li>Is the internal representation of <code>std::text</code> a type parameter. That is, is it configurable for UTF-8, 16, 32, LE and BE, or, is there a single internal encoding which is an implementation detail.</li><li>Is text kept in normalized form, or is normalization done on demand.</li><li>Is there a default sequence view, and if so, code points or grapheme clusters. Or are each to be requested explicitly.</li><li>Does <code>std::text_view</code> meet the requirements to be a view, as many operations may not be O(1) or even amortized O(1), although they may be asymptotic O(1).</li><li>Does <code>std::text</code> implement <code>operator&lt;=&gt;()</code>, only <code>operator==</code>, or are comparisons only by specific named algorithms. There are trade-offs with usability vs surprising run-time costs.</li></ul></div></div></div><div id="inbox-inbox-outline-container-org8f98040" class="inbox-inbox-outline-2" style="font-family:&quot;Times New Roman&quot;;font-size:medium"><h2 id="inbox-inbox-org8f98040"><span class="inbox-inbox-section-number-2">3</span> Near Term Plans</h2><div class="inbox-inbox-outline-text-2" id="inbox-inbox-text-3"><p>Zach Laine is near code complete on his <code>text</code> implementation and plans to submit it for Boost review soon.</p><p>Continue syndicating the idea that text is more complicated than programmers generally believe</p></div></div><div id="inbox-inbox-outline-container-org931780b" class="inbox-inbox-outline-2" style="font-family:&quot;Times New Roman&quot;;font-size:medium"><h2 id="inbox-inbox-org931780b"><span class="inbox-inbox-section-number-2">4</span> 2019</h2><div class="inbox-inbox-outline-text-2" id="inbox-inbox-text-4"><p>Engage with LEWG and LWG for a paper to land directly into the DIS post C++ 2a. SG16 is concerned about having the bandwidth to do more than one core wording paper. If there is a good publicly available reasonably licensed implementation, the value of having a <code>std::experimental::text</code> seems low.<br><br><br>-----<br><br>I believe this accurately captures the current consensus of the group. I would like, with permission of the group, to send something very much like this in to the mailing, in order to appraise the community where we are, and in particular that C++20 std::text isn&#39;t happening. <br><br>Formatting is awful, paper is short enough that the TOC isn&#39;t needed, other comments and criticism welcome. <br><br></p></div></div></div>