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_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/unicode
>>
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>