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. 

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? 

Popularity of named character escapes in other languages suggests that many programmers prefer the ergonomics of \N{OGHAM_SPACE_MARK} over \u1680 .

On Wed, Mar 27, 2019 at 12:40 PM Markus Scherer <markus.icu@gmail.com> wrote:
Hi Tom & SG16,

First, sorry for having dropped off -- I have been swamped with other work and won't make it to today's meeting either.

Second, I would like to ask you to consider if it's necessary to add Unicode properties APIs in the language runtime.
There are widely used libraries like ICU which provide this and more.

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.
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.
(I have been doing this for some 19 years.)

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.

Best regards,
markus

On Wed, Mar 27, 2019 at 8:42 AM Corentin <corentin.jabot@gmail.com> wrote:
As requested by Tom, please find attach D1628R0 which will be discussed during today's meeting \N{WHITE EXCLAMATION MARK ORNAMENT}

Feedback welcome :)

Regards, 
Corentin
_______________________________________________
SG16 Unicode mailing list
Unicode@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/unicode
_______________________________________________
SG16 Unicode mailing list
Unicode@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/unicode