Discuss: Should LocalePreferences have public fields

[zbraniecki]

Issue: Not a fan of this having public fields. But that can be fixed after the PR lands

Originally posted by @sffc in #5729 (comment)

[sffc]

Duplicate of #5786

[sffc]

Actually let's keep this issue open so we have one discussion per thread.

[sffc]

So the main problem here is that DataLocale lives in icu_provider and it needs to be efficiently constructed from this type that lives in icu_locale_core.

Can we just move DataLocale into icu_locale_core?

My personal opinion is that I think it is silly and over-designed to try and keep the types exported from core crates as minimal as possible and put specialized types into other crates. I prefer "useful" core crates: ones that export types that its dependents need.

[sffc]

Conclusion:

• LocalePreferences gets private fields
• It has conversion impls from &LanguageIdentifier and &Locale
• DataLocale moves to icu_locale_core::DataLocale
• LocalePreferences has two conversion functions into a DataLocale: to_data_locale_language_priority(self), to_data_locale_region_priority(self)
• DataLocale gets private fields
• Add a helper function in icu_provider::marker to call the right DataLocale constructor based on the marker
• Also change the associated trait function DataMarker::bind to be a helper function in that module
• Take a birds-eye view of preferences after it is landed in all the crates
  • open question: should preferences be Copy

LGTM: @Manishearth @robertbastian @sffc @zbraniecki

[Manishearth]

Add a helper function in icu_provider::marker to call the right DataLocale constructor based on the marker

This means that every consumer of from_preferences_locale needs to import this free function. Should it be in the prelude instead?

[sffc]

I was thinking the fn would be invoked as icu_provider::marker::locale_for or something like that.

If it's in the prelude, it needs a more specific name. Maybe something like locale_for_data_marker

[Manishearth]

Given that most users need it i think it goes in the prelude then.

Or should be a trait method on DataMarker.

[Manishearth]

DataLocale's private fields issue split out to #5989