Resolution between API options and -u- Locale extensions (migrate constructors to ICU4X Preferences)

[sffc]

ICU4C and ICU4J are inconsistent in honoring -u- extensions. Sometimes the formatters obey them, or not. They also support setters instead of -u-. Can we do something in ICU4X to unify the pattern around the resolution between -u- and API options?

[sffc]

@mihnita - Every formatter should look at -u- and obey the parts that are relevant.

@zbraniecki - There should be a common resolution logic helper.

@nciric - We largely deal with this in ECMA-402.

[sffc]

Deliverable: make the shared helper class. A utility. Document in the style guide.

[sffc]

Revisit in 0.3

[sffc]

@sffc to draft a design doc.

[sffc]

See #2136 for additional discussion.

For ICU4X 1.0 we agreed to move forward with option 3 above, but we will definitely continue to consider adopting Preferences in ICU4X 2.0

[zbraniecki]

For ICU4X 1.0 we agreed to move forward with option 3 above,

Is that try_new(locale: DataLocale) or try_new<L: Into<DataLocale>>(locale: L) ?

[sffc]

it is try_new(locale: &DataLocale) as laid out in #2136 (comment)

[sffc]

Notes about icu_preferences integration plan:

• @zbraniecki - There's some work still to be done on provider/preferences integration. For example: https://github.com/unicode-org/icu4x/blob/main/utils/preferences/tests/dtf_os_prefs_tests.rs#L12
• @sffc - I can look at this, but probably not until August.

[sffc]

Plan:

• @robertbastian to open a PR migrating either PluralRules, FixedDecimalFormatter, or Collator to icu_preferences by October 1
• If all looks OK, @zbraniecki to migrate remaining crates during the month of October

[robertbastian]

I've tried to migrate icu_collator and have hit the following road blocks:

• CollatorPreferences wraps an optional LanguageIdentifier. It is unclear to me what the difference between None and Some(LanguageIdentifier::UND) is. We have so far treated these the same
• CollatorPreferences wraps an owned LanguageIdentifier. Constructing CollatorPreferences from &LanguageIdentifier or &Locale requires a clone.
• ResolvedCollatorPreferences does not wrap a DataLocale
  • We have to create a DataLocale from a &LocaleIdentifier each time we try to load data.
  • There is nowhere to store a subdivision subtag, which is required according to https://docs.google.com/document/d/1Rrp1IxycTu2CETceUOQRcwVECXsv0pOJIAUMPdYlHYY

[robertbastian]

My proposal would be:

• CollatorPreferences borrows a LanguageIdentifier, so it gains a lifetime
• ResolvedCollatorPreferences stores a DataLocale internally, so it doesn't need a lifetime, can be trivially converted to DataIdentifier, and is Copy.

[robertbastian]

Another issue: resolving preferences requires data. Where does this data come from?

[sffc]

I feel like ResolvedPreferences is trying to do multiple things at once:

1. Put together the variables we need for data loading
2. Return the resolved options to the user

But, these are two separate operations. Only the second one needs data, and the first one needs to keep track of extra things like -u-rg, which is required for region-priority fallback.

[Manishearth]

Everyone is on Preferences now, this should be done.