Implement Into<Locale> for preference structs.

[jedel1043]

This will simplify boa-dev/boa#4589 in the future.

[sffc]

Thanks! Would you mind adding some round-trip test cases?

[sffc]

Question/Issue: Will every value always have a unicode extension value?

[robertbastian]

I don't think this makes much sense conceptually. A locale that is obtained from say DateTimeFormatterPreferences cannot be used for anything else, as the conversion into the preferences is lossy. Preferences that are not used by DTF won't round-trip.

[sffc]

The use case is

new Intl.DateTimeFormat("en-u-ca-chinese-co-pinyin").resolvedOptions().locale
// 'en-u-ca-chinese'

[robertbastian]

Preferences are not designed to be the resolved options, they are not aware of any fallback that happens. Does resolvedOptions() just need to throw away irrelevant extensions, or also produce the result of data resolution?

It's very counterintuitive for From to be implemented in both directions, but not round-trip. I think this should be into_locale() or something. Another approach that might suffice for Temporal would be to implement Writeable on preferences to get the string representation.

[sffc]

It appears to do filtering of relevant extension keywords, removing unsupported values, and resolving aliases.

new Intl.DateTimeFormat("en-u-ca-ethiopic-amete-alem-co-pinyin-nu-latn1").resolvedOptions().locale
'en-u-ca-ethioaa'

https://tc39.es/ecma402/#sec-resolvelocale

[sffc]

It's very counterintuitive for From to be implemented in both directions, but not round-trip.

Well, preference-to-locale is the lossless direction. The direction we currently have is the lossy direction.

I think this should be into_locale() or something.

I am always happy with concrete functions over From impls

Another approach that might suffice for Temporal would be to implement Writeable on preferences to get the string representation.

We could do both, but I see no good reason to export Writeable without exporting the Locale conversion, since you can re-parse the writeable into a Locale and just be less efficient.

[robertbastian]

Well, preference-to-locale is the lossless direction. The direction we currently have is the lossy direction.

You can't really talk about lossless if you only have one direction. Right now, we have a Locale domain A and a preferences domain B (which is different from A). From<Locale> for Preferences is a function from domain A to domain B (which is not bijective, but that's fine). As soon as you add the B to A function though, not having bijectivity is very unexpected.

We could do both, but I see no good reason to export Writeable without exporting the Locale conversion, since you can re-parse the writeable into a Locale and just be less efficient.

Yes, but using that Locale is also generally wrong, so I like making it more complicated.

[jedel1043]

@robertbastian Hmm, what about only implementing a conversion into extensions::unicode::Unicode instead? TBH we don't really need the full Locale in the linked PR, we just need the unicode extensions part. Does that implementation make more sense?

[robertbastian]

I would approve fn as_keywords(&self) -> unicode::Keywords.

[sffc]

A potential issue with that signature is whether we should include -u-rg and -u-sd in the keywords. If we don't include them, then we aren't including all the keywords. If we do include them, then we aren't returning all of the region information.

[Manishearth]

If it's lossy perhaps we should have to_locale_lossy() or to_locale_for_resolved_options()?

[robertbastian]

If we do include them, then we aren't returning all of the region information.

can you elaborate what you mean by this? we're returning all unicode keywords that are relevant to the preferences

[sffc]

If we do include them, then we aren't returning all of the region information.

can you elaborate what you mean by this? we're returning all unicode keywords that are relevant to the preferences

The Preferences struct contains LocalePreferences plus zero or more keywords relevant to the formatter. It seems wrong to pull only some of the data out of LocalePreferences without returning all of the data from LocalePreferences.