LocalePreferences: bikeshed

[sffc]

LocalePreferences landed in #5729. Two things I want to decide about it before it gets shipped:

1. Name. Not a big fan of the name. These are not preferences for a locale. It is a locale associated with a preference bag. I think PreferencesLocale is a better name, but would also be happy with naming it "what it is" such as LanguageIdentifierWithRegionExtensions, for example.
2. Public fields. I don't consider the design of this type 100% finalized. The CLDR spec it is implementing is still a concept, not yet landed in UTS 35. I would prefer it to have private fields. EDIT: Moved to Discuss: Should LocalePreferences have public fields #5785

@zbraniecki @robertbastian

[sffc]

• @zbraniecki To reiterate my reasoning: I don't think there is value of this struct beyond ergonomics of internal operations. For me, it is almost the same as if we listed the field in the main preference bag. These are the "preferences related to locale". I would be opposed to PreferencesLocale because it conveys that this is a type of locale that has value as a standalone struct, but I see the only value is storage of fields and conversion to DataLocale.
• @sffc OK.
• @robertbastian I like having the type.

#[non_exhaustive]
pub struct ListFormatterPreferences {
    pub locale_prefs: LocalePreferences,
}

• @robertbastian The fields of ListFormatterPreferences should be private, right?
• @sffc You shouldn't ever convert a Locale to a LocalePreferences in user code, because you want to retain other Unicode extensions like numbering system. No strong opinion on the field being public overall
• @zbraniecki If we make them private, we can make them public later

Conclusion:

• For naming: keep LocalePreferences.
• Make the locale_prefs field of preferences bags private.

LGTM: @sffc @zbraniecki @robertbastian