<div dir="ltr">&gt; <span style="color:rgb(0,0,0);font-family:sans-serif;font-size:medium">ICU supports customization of its internal code unit type, but </span><code class="gmail-highlight" style="font-family:Menlo,Consolas,&quot;DejaVu Sans Mono&quot;,Monaco,monospace;font-size:0.9em;break-inside:avoid;padding:0.1em;border-radius:0.3em;background:rgb(245,242,240);color:rgb(0,0,0)"><span style="color:rgb(153,0,85)">char16_t</span></code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:medium"> is used by default, following ICU’s adoption of C++11.</span><br><div><br></div><div>Not quite... ICU supports customization of its code unit type <u><i>for C APIs</i></u>. Internally, and in C++ APIs, we switched to char16_t. And because that broke call sites, we mitigated where we could with overloads and shim classes.</div><div><br></div><div>This was all quite painful.</div><div><br></div><div>As for char8_t, I realize that you think the benefits outweigh the costs.</div><div>I asked some C++ experts about the potential for performance gains from better optimizations; one responded with a skeptical note.</div><div><br></div><div>If you do want a distinct type, why not just standardize on uint8_t? Why does it need to be a new type that is distinct from that, too?</div><div><br></div><div>Best regards,</div><div>markus</div></div>