C++ Logo

sg16

Advanced search

Re: [SG16-Unicode] UCD and Private Use Area

From: Steve Downey <sdowney_at_[hidden]>
Date: Thu, 29 Aug 2019 17:56:45 -0400
ICU, as a reference, only allows customizing the database at build time,
not at runtime. They do call out custom properties for the PUA, though.

http://userguide.icu-project.org/strings/properties#TOC-Customization


On Thu, Aug 29, 2019 at 5:34 PM Corentin Jabot <corentinjabot_at_[hidden]>
wrote:

> Unicode advise not doing that at all
> http://www.unicode.org/faq/private_use.html#pua10
>
> And the properties are immutable across the universe for a given version
> of Unicode. Algorithms etc depend on that
> P1628 supports versioning but i guess that might not last
>
> On Thu, 29 Aug 2019 at 13:05, Lyberta <lyberta_at_[hidden]> wrote:
>
>> I wanted to tinker with Private Use Area code points and I thought what
>> would be the standard way to do that. And it is obvious that we need a
>> UCD class and use it to hold the user-defined properties of Private Use
>> Area code points.
>>
>> This is completely opposite of P1628.
>>
>> We define a new class std::unicode::character_database (established
>> name, although I'd prefer calling it std::unicode::code_point_database)
>> and similarly to std::source_location it has static function default()
>> that will return the reference to const default UCD. Obviously, the
>> entire class should be constexpr.
>>
>> Now, my initial idea was to make only Private Use Area mutable while the
>> rest is const but then it occurred to me that it will deny some nice
>> possibilities such as 3rd party libraries shipping older and newer
>> versions of UCD that is shipped with the standard library.
>>
>> Essentially, I think the entire database should be mutable.
>> std::unicode::character_database should be a value type but I guess we
>> may word it so it is possible to implement mutations from default as a
>> separate internal state while the rest of the database simply links to
>> default one, like copy-on-write.
>>
>> I don't have the API or the wording yet. This is just thoughts at this
>> point but it seems like P1628 is not the way to go at all.
>>
>> _______________________________________________
>> 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
>

Received on 2019-08-29 23:56:58