<div dir="ltr">This work came out of supporting unicode compile time regular expressions, and there doesn't seem to be a good alternative way of providing this data. Nevertheless, it's a fair question to ask if the api should be exposed to clients, or be an implementation detail. <br><br>If data structures need to be changed, it's not only a maintenance burden but potentially a specification burden. Or do you mean rebuilding tries, or new parsers of the unicode database? <br><br>Popularity of named character escapes in other languages suggests that many programmers prefer the ergonomics of \N{<span style="color:rgb(0,0,0)">OGHAM_SPACE_MARK} over \u1680 .</span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 12:40 PM Markus Scherer <<a href="mailto:markus.icu@gmail.com">markus.icu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Tom & SG16,<div><br></div><div>First, sorry for having dropped off -- I have been swamped with other work and won't make it to today's meeting either.</div><div><br></div><div>Second, I would like to ask you to consider if it's necessary to add Unicode properties APIs in the language runtime.</div><div>There are widely used libraries like ICU which provide this and more.</div><div><br></div><div>Many users will want to be able to use the latest version of Unicode, which will tend to be newer than what their compiler provides.</div><div>There are also enough changes in Unicode properties that data structures or parsers etc. sometimes need to be adjusted, so you have a maintenance burden.</div><div>(I have been doing this for some 19 years.)</div><div><br></div><div>And finally, I personally think that the ROI for the name property is low. As noted in the document, the data is large, but also a long \N{dozens of letters} string is not very readable. I find it's just as easy to use \uhhhh escapes with a simple code comment for which character that is, and if it's obvious (like a regular printable letter) you use the character itself anyway.</div><div><br></div><div>Best regards,</div><div>markus</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 8:42 AM Corentin <<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>As requested by Tom, please find attach D1628R0 which will be discussed during today's meeting \N{WHITE EXCLAMATION MARK ORNAMENT}</div><div><br></div><div>Feedback welcome :)</div><div><br></div><div>Regards, </div><div>Corentin</div></div>
_______________________________________________<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></div>
_______________________________________________<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>