Manish Goregaokar
Manish Goregaokar
not 100% convinced this is needed over FFI but it's a weak opinion
Discussion on locid_transform/locid_fallback - @sffc - I see a few options 1. Keep `icu_locid_transform`. Re-export the stuff from `icu_loc[ale/id]` that it currently re-exports 2. Keep `icu_locid_transform` and remove everything except...
We got `icu_locale`: https://crates.io/crates/icu_locale (crates.io rules prevent renaming underscores to dashes, _however_ crates.io rules sometimes allow empty squatted crates to be taken over, and `icu-locale` counts since it's empty and...
- @sffc - The new `icu_locale` crate will contain, as discussed, all locale-related, data-driven code. This includes: - Locale canonicalizer - Locale directionality - _Maybe_ LocaleInfo (week info, etc... see...
Bikeshed suggestions for `icu_bikeshed`: - `icu_compiled_data_utils` - `icu_locale_mantle` ("not core, but still somewhat core") - `icu_locale_core2` - ...
I like locale_ops, locale_data_utils, locale_support, and locale_mantle
Discusion with Zibi present 3 crates: - `icu_locale_core`: structures (currently `icu_locid`) - `icu_bikeshed`: fallbacking and other locale-related machinery for compiled data - `icu_locale`: re-exports `icu_locale_core`, `icu_bikeshed`, and adds data-driven functionality...
I think this is a good idea. No strong opinion on trait name. ZeroTrieVariant or ZeroTrieKind both seem fine.
That would be cool. I've wanted to amortize space between aux keys by storing them at a different layer in blob