Enumerated properties should have to/from ICU4C APIs

[Manishearth]

Our enumerated properties are opaque wrappers around integers, using the same values used by ICU4C.

It's reasonable to abstract away our internal implementation, but the ICU4C values are pretty standard across i18n code, and it's reasonable to wish to access these values.

We should offer to/from u8 (or u16) APIs.

I propose we name them to_icu4c_value() and from_icu4c_value(), linking to ICU4C docs. There is no fallibility, unknown values are accepted.

I am not opposed to just having Into/From and documenting the impl as stably producing ICU4C values.

cc @sffc @echeran @robertbastian

[sffc]

I'm fine adding these, since as you observed this is already part of our observable behavior via TrieValue. Prefer explicitly-named functions as usual.

Perhaps to_icu4c_int or to_icu4c_discriminant?

[Manishearth]

Fine by me

[sffc]

The PR uses the names in the OP. I don't have a record of us deciding on those names over #6067 (comment).

[robertbastian]

I implemented @Manishearth's proposal as you proposed two names. I'll leave this open if you want to find-replace the names.

[sffc]

My impression of the names:

1. to_icu4c_value sounds like it should return a ffi type for directly interoperating with ICU4C. But it's also fine.
2. to_icu4c_discriminant is the most accurate description of what the function returns. It also sounds more strange, which is fine, because most users won't need this function unless they specifically want the ICU4C discriminant for some reason (e.g. harfbuzz).
3. to_icu4c_int is also correct, but maybe less clear.

So my preference on the name would probably be: 2 > 1 > 3

[Manishearth]

I like 2 as well. No strong opinion, 2 ~> 1 > 3.

[echeran]

I'm fine adding these, since as you observed this is already part of our observable behavior via TrieValue. Prefer explicitly-named functions as usual.

Perhaps to_icu4c_int or to_icu4c_discriminant?

I like to_icu4c_int. ICU4C expresses the values as int32_t. I do not prefer the alternative option _discriminant because that is a term I only see in Rust, and it is not used in ICU4C. I do not prefer the OP option to_icu4c_value because "value" is an overloaded term that could refer to the Unicode Property Value or the integer value that one might get back from by the ICU4C CPTrie

[sffc]

Another suggestion: to_raw_icu4c_value

[sffc]

@eggrobin pointed out that C enums are integers; there is no casting involved. However, @Manishearth points out that this depends on -fpermissive in C++.

With this information, I am slightly more okay with _value. My vote changes to:

Choices:

1. to_icu4c_value
2. to_icu4c_discriminant
3. to_icu4c_int
4. to_raw_icu4c_value

Vote:

• @sffc: to_raw_icu4c_value ~> to_icu4c_discriminant ~> to_icu4c_value ~> to_icu4c_int

[Manishearth]

@Manishearth: to_icu4c_value ~> to_icu4c_discriminant > to_icu4c_int ~>> to_raw_icu4c_value

(I do not think that raw is necessary and it feels like additional info to confuse people)

[eggrobin]

@Manishearth points out that this depends on -fpermissive in C++.

That is a GCC flag. In C++, you need a cast; there is no such thing as fpermissive in clang or msvc.

[sffc]

@echeran Please vote.