<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 28, 2019, 9:33 AM Lyberta &lt;<a href="mailto:lyberta@lyberta.net">lyberta@lyberta.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Yes - The longer the namespace, the more likely people are to write &quot;use<br>
&gt; namespace std::unicode;&quot;<br>
&gt; which defeats the purpose - we have bad precedent with std::filesystem.<br>
&gt; Uni is sweet and short, I guess something like uncd would work too,<br>
&gt; it&#39;s not as much about the name as it is about the number of letters<br>
<br>
Uni is too ambiguous, uncd is better but very ugly. I have no problem<br>
with std::filesystem.<br>
<br>
&gt; <br>
&gt;&gt;<br>
&gt;&gt; Unicode always uses the term &quot;code point&quot;, not &quot;code point&quot;:<br>
&gt;&gt; <a href="https://www.unicode.org/glossary/#code_point" rel="noreferrer" target="_blank">https://www.unicode.org/glossary/#code_point</a><br>
&gt;&gt;<br>
&gt;&gt; So the name should be std::uni[code]::code_point.<br>
&gt; <br>
&gt; <br>
&gt; Bike-shedding and while that might be true, is there any gain in<br>
&gt; information ?<br>
<br>
&quot;Codepoint&quot; feels very wrong, almost as wrong as strlen and the rest of<br>
C library.<br>
<br>
&gt;&gt; In my experience, I never need the code point because surrogates are not<br>
&gt;&gt; allowed in valid UTF. I only ever need unicode scalar values:<br>
&gt;&gt; <a href="https://www.unicode.org/glossary/#unicode_scalar_value" rel="noreferrer" target="_blank">https://www.unicode.org/glossary/#unicode_scalar_value</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; This api (and TR44) is defined in term of code points<br>
&gt; it&#39;s actually well behave from all integers from 0 to 0xFFFFFFFF<br>
<br>
I guess, but do we really want our users to shove random integers in it<br></blockquote></div><div><br></div><div>Yes. I really want a wide contract there</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; The whole reason I am using that codepoint type (which is more a<br>
&gt; __codepoint_hack type) here is to delete<br>
&gt; use with char and wchar_t which is non nonsensical.<br>
&gt; Aka a code point type is not part of this proposal.<br>
<br>
That&#39;s why my design intended those functions to be member functions of<br>
code point (or scalar value) type. Since constructor is explicit, you<br>
can&#39;t shove char or wchar_t in there<br></blockquote></div><div><br></div><div>That gives the impression these type may have state or caching which they really shouldn&#39;t have. But otherwise yes, if your objects have a wide contract all the way through - which they won&#39;t - having these methods in a type is possible.  I don&#39;t think we gain in usability thought, especially it makes it harder to use these query in ranges.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; <br>
&gt; The feedback I got is to just not care and just use uint32_t instead and<br>
&gt; let people<br>
&gt; shoot themselves in the foot.<br>
<br>
What about systems where CHAR_BIT != 8, 16 or 32? std::uint32_t is<br>
optional, do we want Unicode on such systems? I&#39;m myself on the edge<br>
between char32_t and std::uint_least32_t.<br></blockquote></div><div><br></div><div>Good point</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;&gt; I&#39;m writing a competing proposal where I want to propose<br>
&gt;&gt; std::unicode_code_point and std::unicode_scalar_value that have explicit<br>
&gt;&gt; constructors from char32_t and explicit member function .value() to get<br>
&gt;&gt; char32_t back. I think this is the only way forward. char8_t, char16_t<br>
&gt;&gt; and char32_t are dumb types that have horrible names, we should o.nly<br>
&gt;&gt; use them as a transition mechanism.<br>
&gt;&gt;<br>
&gt; <br>
&gt; In my experience, you will find that it is a very difficult and verbose api<br>
&gt; to use,<br>
&gt; especially that explicit value method.<br>
&gt; I do think char32_t is fine as it was always supposed to be a code-point<br>
&gt; (or even, a code unit which also happens to be a codepoint, it&#39;s really the<br>
&gt; most basic building bloc) which it is.<br>
&gt; I do not think scalar value are that important as it is difficult to form<br>
&gt; something that it is not a scalar value as soon as we have the right<br>
&gt; &quot;unicode sandwich&quot; model<br>
&gt; where encoding or input that may produce non-scalar value code point have<br>
&gt; to be decoded at i/o boundary<br>
&gt; then your scalar value just becomes a contract that you can sprinkle<br>
&gt; everywhere.<br>
<br>
Yes, contract or invariant means strong type, not dumb char32_t<br></blockquote></div><div><br></div><div>TR 44 is purposefully dumb by design too. </div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>