Add conversions for unicode-script

[robertbastian]

Context: #7266 (comment)

[Manishearth]

From the other issue:

fontique has a custom Script type that is constructible from both icu_properties::props::Script and unicode_script::Script. I assume they made it constructible from unicode_script::Script for a reason. It would make sense for them to use one or the other instead of creating yet another script type, but that would require this conversion to exist in either ICU or unicode_script.

I'd like to know that reason. I know some of the linebender ecosystem is using unicode-script but they're also considering switching to ICU4X. It feels inefficient for an application to carry both. I understand that large applications ultimately can't control their dependency sprawl as easily so it's going to happen, but it would be nice to wait for people to ask us for it with strong reasons.

Unicode-script was primarily created as a crate for use by rustc for mixed-script detection (via unicode-security). Unlike some of the other unicode-rs crates, there's a less strong maintenance guarantee there when it comes to Unicode updates and such. I'd rather not have unicode-script be a part of ICU4X's public API if I can help it, especially in case we decide to make breaking changes.

[robertbastian]

It feels inefficient for an application to carry both.

Yes you certainly shouldn't use the data in both icu::properties and unicode-script. However, using the enums is totally fine, and there are existing APIs using the unicode-script enum that we're not going to replace with the icu::properties enum.

I'd rather not have unicode-script be a part of ICU4X's public API if I can help it, especially in case we decide to make breaking changes.

What changes would that be?

[robertbastian]

I know some of the linebender ecosystem is using unicode-script but they're also considering switching to ICU4X.

And this would make it easier for them to migrate, given that their current API accepts the unicode-script enum.

FWIW icu::properties also integrates with unicode-bidi, and we have a conversion between our BidiClass and its BidiClass.

[Manishearth]

And this would make it easier for them to migrate, given that their current API accepts the unicode-script enum.

If it's about migration they can do a temporary thing.

FWIW icu::properties also integrates with unicode-bidi, and we have a conversion between our BidiClass and its BidiClass.

Right, because icu::properties chose to not implement the bidi algorithm. unicode-bidi is a part of ICU4X's library story. unicode-script is not.

What changes would that be?

Unclear! It's not something we've seriously looked at from a polishing perspective.