Custom variants for icu_preferences about icu4x HOT 1 OPEN

I have a solution that I can re-add on top of the macros I'm introducing that makes each enum have Custom(unicode::Value) variant that catches all unknown values, making the enum look like:

enum Collation {
    Standard,
    Search,
    Phonetic,
    Pinyin,
    Searchjl,
   Custom(unicode::Value)
}

and then -u-co-search ends up as Collation::Search but -u-co-foo ends up as Collation::Custom(value!("foo")).

This is easy to add, but it brings an architectural question - is there a value in having enum at all then?

For keys that have "open ended" values such as Currency, I use struct Currency(TinyAsciiStr<3>) to represent an open ended validated range of currencies.
If we add Custom, then we could turn Collation, Calendar etc into such struct Collation(Subtag) and struct Calendar(Value) and get rid of enum with known variants at all.

I'm torn on whether this is a better design. I see two use cases of icu_preferences keys API:

• in code as if preferences.collation == Collation::Search
• in data as let data = payload.get(preferences.collation)

In the former the ergonomics of having "known" variants is great, while in the latter it doesn't matter - we retrieve a key from some collection by key, so we either need to serialize the known variant, or we can use Subtag/TinyStr/Value as key.

from icu4x.