Ergonomics improvements for property types

[cmyr]

In the course of using icu_properties I've run into a number of little ergonomics issues that seem like they could be improved:

• mapping between script names and Script instances is unintuitive. I would expect the majority of users are using baked-in data, which means it should be possible to have methods on Script for doing these conversions, like Script::short_name or Script::long_name, or a Script::from_short_name constructor.
• similarly for mapping from a codepoint to a script; when baked data is available, couldn't we just have a Script::for_char constructor?
• alternatively, instead of making me manually name and instantiate types like CodePointMapData, couldn't we have a type method on the relevant type, so that I could call BidiClass::codepoint_map? In the case where this is borrowed static data this could even be available as a const, like BidiClass::CODEPOINT_MAP or something?

In any case these are just a couple ideas, and someone who has spent more time on this project might have better ones.

[Manishearth]

In general I agree. The overall design of ICU4X is to put data loading front and center, however I actually do expect most pure Rust users to just use compiled data, and adding more convenience APIs seems good.

I suspect most disagreement will be from the angle that data loading must be explicit.

[sffc]

I think there are numerous advantages toward making calls through the data structures explicit rather than implicit. However, I'm amenable to convenience constructors that improve discoverability.

For example:

// Current:
PropertyNamesLong::<Script>::new().get(Script::Adlam)
CodePointMapData::<BidiClass>::new().get('🎃')

// Alternative:
Script::long_names().get(Script::Adlam)
BidiClass::code_point_map().get('🎃')

// Also allows for:
Script::long_names_with_buffer_provider(&provider).get(Script::Adlam)
BidiClass::code_point_map_with_buffer_provider(&provider).get('🎃')

[Manishearth]

Currently there is no way to check the value of a binary property over FFI without allocating. This seems like a dealbreaker for ICU4C replacements: most code using iCU4C for "singleton type" APIs will not be persisting some data object and cannot be easily migrated to doing so.

This might also apply to casemapper APIs: I'm looking at the usage of tolower/toupper in bionic as well.

[Manishearth]

Alternatively we can try returning &'static CodePointSetData8 (etc)? I believe Diplomat supports this but it may be buggy. Still suboptimal to go over an FFI call here.

[Manishearth]

No, the duplication with the Borrowed types is going to be a problem here.

[Manishearth]

I'm going to file two related issues: one to add convenience methods here as per my plan, and one to talk about the broader problem of ffi singletons.

[Manishearth]

Issue for enum props: #6049

Issue that covers the broader problem including binary props: #6050

[cmyr]

I do want to clarify that my concern is exclusively with properties & UCD data, where it really feels like it would take a pretty extreme case to want custom data? My sense is that there's been a ton of thought and engineering work put into supporting the diverse needs of localization clients, but that the sorts of API decisions that make sense in that domain are a poor fit for a unicode properties API.

[Manishearth]

Custom data isn't the only goal, being able to load data dynamically is another goal, and that'll be more common.

But yes, I agree, certain of our APIs (what I tend to call "Singleton APIs", see issue) should prioritize good ergonomics for compiled data users.

The API here was driven by consistency with the idea that more things could be added later

[sffc]

There are use cases for custom UCD data, such as testing pre-release UCDs (unicode-org/unicodetools#1004), so the machinery should exist, but I agree that we can have convenience APIs for properties.