When icu::locid::extensions::unicode::Value has a single-segment value, make it borrowable as &str

[hsivonen]

It's inefficient to write icu::locid::extensions::unicode::Value into a String in order to get a &str, especially when icu::locid::extensions::unicode::Value holds only one segment.

I suggest adding a method that returns Option<&str> with Some(...) if there is exactly single value segment and None otherwise. This would improve the API for single-segment use cases, such as collations.

[zbraniecki]

hmm, treating single value segment differently from multi value segment seems to be leaking internal structure onto the API.

For extension types that hold only single part, we could do as_str() projecting it from TinyStr, but we can't extend it to multi-part values.

For multi-part, if your goal is comparisong, I think a compromise might be to add PartialEq<str> which splits the str by - and compares it to parts.

How does it sound?

[sffc]

How about changing the data model of unicode::Value to store a hyphen-delimited String.

[sffc]

Depending on the use case, I'd also be happy with a cmp_bytes on Value (or PartialEq<[u8]>, depending on #1709)

[hsivonen]

My goal isn't only comparison but also (in the case where special comparisons don't match) passing the extension value to the provider in the variant field of ResourceOptions.

[sffc]

My goal isn't only comparison but also (in the case where special comparisons don't match) passing the extension value to the provider in the variant field of ResourceOptions.

I have a draft PR open that changes ResourceOptions to support extensions::unicode::Value directly so that you don't need to convert to String.

[zbraniecki]

In #1833 I had to figure out how to handle it. I was able to workaround this by just comparing to a const Value. I am a bit reluctant to forgo the value of Copy to store it as a String. I think 99% of cases it will be a single TinyStr and I'd like to optimize for that use case, while keeping the API working for both single item and multi item.

[sffc]

Yep; in #1750, icu_locid::extensions::unicode::Value is used more broadly in the data loading infrastructure, and I think we should just continue to use that type everywhere that locale preferences are being handled, rather than going back and forth to String.